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));

openssh-3.3p1/monitor_mm.c:88-90

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;

linux-2.0.36/mm/mmap.c:171-198

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.


But it was possible …

The other day Rob comes into my room. “I need some help,” he said. “I made a mistake on my Sun box and I'm wondering if you could help me.”

Turns out Rob renamed a critical directory (/usr) and not only were most of the commonly used programs stored under it, but so were all the runtime libraries used by these commands, so nothing would run except for a few statically compiled programs (programs that contained the libraries they needed inside themselves). Nothing but the shell, mount, umount and fdisk were available.

Now, I'm used to recovering with minimal commands but there was no way to rename a file, or change its permissions.

Heck, we were worse off than those in the classical Unix horror story. Had I known SPARC assembly and how to call the kernel for Solaris 7, then yes, we might have had a chance. Create the smallest binary to either create a directory, or to rename a directory, and we'd be set. While it seems hard to create a file without the normal commands one usually uses for such a task, echo is a shell built-in, and using that with redirection and the ability to specify arbitrary octal constants (with the “\nnn” notation supported by the shell) and you have your program.

Okay, so you can't change the permissions on it, so pick some file you no longer need with execute permissions and write over that, then you'll be able to execute the hand-written program to get back into business.

Granted, that's if either of us new SPARC assembly and the executable format.

Since neither of us did, there wasn't much that could be done.

Well, maybe mounting the drives on another Solaris box, but Rob really didn't care all that much since we was planning on reinstalling Solaris on that system anyway.

But it was possible …


Chalk marks the millimeter waves of space …

I've seen several sites now mentioning warchalking and I'm wondering just how long it will be before The Facility in the Middle of Nowhere is marked?

In other news, the other day I noticed that Publix (the local supermarket) now sells sidewalk chalk.

Hmmmm …

Obligatory Picture

[It's the most wonderful time of the year!]

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: http://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

http://boston.conman.org/2000/08/01

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-2019 by Sean Conner. All Rights Reserved.