The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Tuesday, June 25, 2002

Sploits, upgrades and updates

I avoid upgrading, not so much to avoid version fatigue as that what I have works and as the saying goes, “if it ain't broke, don't fix it!”

So it was rather surprising to find myself upgrading two important packages this week. The first being Apache. In looking over the security bulletin, while it wouldn't allow one to get remote access on my particular platform (a 32 bit operating system) it could lead to a denial of service attack so I decided for performance reasons to upgrade (unlike most sysadmins I know, I'm not so paranoid about people gaining access that my systems are unusable but that's a rant for another time).

The Apache upgrade went smoothly.

The other package I needed to upgrade however …

I received word from Mark about an upcoming OpenSSH exploit that will allow remote root access! While I may be relaxed about security, I'm not stupid either.

Reading up on it, no patches are available, but if you run the latest version with a certain option, the bug that allows the exploit is still there, but it can't be exploited.

Okay …

So I download the latest version of OpenSSH, configure, compile and install the code on my development server (I'm not about to install it untested on my colocated box—if I screw up it's a long and painful process to fix). Install and run the new sshd server. Okay, seems to be running. Attempt to log in.

Apparently it accepts incoming network connections, then promptly drops the connection. I can't log in.

Odd …

I check the log files and for every attempt I made to log in, find the following entry:

Jun 25 04:14:56 linus sshd[13062]: fatal: mmap(65536): Invalid argument

The number being fed to mmap(), 65536, is suspicious but given the platform I'm on, shouldn't be invalid. Time to check the source to OpenSSH:

address = mmap(NULL, size, PROT_WRITE|PROT_READ, MAP_ANON|MAP_SHARED, -1, 0);
if (address == MAP_FAILED)
	fatal("mmap(%lu): %s", (u_long)size, strerror(errno));


This is the only place in OpenSSH that calls mmap() so I have the right location. And since mmap() is complaining about getting an invalid argument, it's time to determine just which argument mmap() is complaining about.

Now, normally, mmap() is used to map files into memory, but it does have its other uses (such as here, which seems to be allocating a section of memory to be shared with something else). Going through the paramters, the first is the starting address, which here is NULL but that's allowed; it just tells mmap() to use any available address that matches the criteria. The length (65536) should be okay for this platform. The protection of the memory region (PROT_WRITE and PROT_READ) look good, as to the options (a shared, anonymous region of memory). The file to be used (-1) looks odd; the man page doesn't say anything about not specifying a file, but the offset to use in the file (which isn't specified) looks good.

Now, since the man page doesn't mention anything about not specifying a file, now it's time to check the kernel sources to see what Linux might be rejecting.

if (file != NULL) {

} else if ((flags & MAP_TYPE) != MAP_PRIVATE)
	return -EINVAL;


Here, file is NULL so the else clause kicks in, and well … there you go. OpenSSH is asking for MAP_SHARED but Linux 2.0.36 doesn't support that option. Neither does Linux 2.0.39 (what my colocated server and firewall run).

Linux 2.4 however (at least 2.4.18 which I had immediate access to) does support the usage of mmap() than OpenSSH requires.

But due to a lot of reasons, upgrading my servers from Linux 2.0 to 2.4 is pretty much out of the question (at least for any reasonable amount of time and effort), and taking out the offending code in Linux 2.0 is out, until I can test it and make sure it works, so in the mean time, my only real hope is security through obsolescense.

I recompiled the version of OpenSSH I am using with different compiler options to make an exploit less likely to work, since exploits are quite dependant upon both the architecture and code layout (and operating system, plus maybe kernel versions of said operating system) this should be good enough to keep all but the most dedicated off my systems.

Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.