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 …
