I'm wrapping up my first beta disk for (*sigh*) US-only GNU/Linux security tools. As many of you know, this quasi-distribution was the cause of some recent discussions. See [1].
This quasi-distribution contains material which definitely *cannot* be exported without permission from my dear uncle: - an initial MIT Kerberos 5 package. Kerberos 4 is available from non-US, but the foreign K5 package is apparently not ready for regular use. - several packages recompiled to use Kerberos 5/GSSAPI authentication: CVS, LPRNG, IMAP. Packages which use Kerberos 4 authentication (e.g., AMANDA) have not been recompiled since they can be distributed in non-US. Actually, these packages are already exported. But nobody outside of the US/Canada can rebuild them. :-( - Kernels 2.0.35 and 2.0.36 rebuilt with support for the Berkeley (cypherpunks) encrypted file system. The loop device changed significantly in 2.2.0, so I don't know when support will be available in that line. (uname: 2.0.x-efs). See the article in Linux Journal about a year ago. (This also requires a patched 'mount' from util-linux 2.9g, and that in turn might require newer packages.) (These patches may also be available outside of the US; if so, someone else could package these kernels for nonus.) - xfree86 rebuilt with support for XDM-AUTHENTICATION-1. Unlike MIT-COOKIES-1, this authentication method is secure even when a network sniffer is present. The xfree86 MIT-KERBEROS-5 code expects a different API than the MIT k5-1.0.5 distribution, so I don't have support for it yet. (This is 3.3.3.1 with modified makefiles from a December slink snapshot.) - "non-US" mirrors for hamm and slink, since I'm not repackaging files already available from those sites. Before you dismiss the entire idea of US-only packages, I need to point out that several large companies are already folding Kerberos authentication into their tools. Windows NT 5 may not be out for years, but some cable modem systems use Kerberos authentication (or a derivative of it) today... and these same cable modem system use the lack of Kerberos support in Linux as a reason for not supporting it. (The Kerberos support in Windows 9x may only be a crippled DLL... but it's on the "free software" disk these companies hand out.) Likewise, some universities use Kerberos authentication for their on-campus networks. In other words, is this glass "half full" or "half empty"? This disk also contains some material which should be exportable, and I'm offering them for incorporation into Debian (modulo the comment below): - kernels 2.0.35 and 2.0.36 patched with "secure linux 0.6". (http://www.false.com/security/linux/). I don't have too much doubt about the value of the patches (do a yahoo search on "+secure-linux +patch", but in light of "moduleinfect.c" and the problems with TCP-wrappers and util-linux I'm paranoid that the patches might have been corrupted. Some documentation follows. (uname: 2.0.x-s). - rainbow: the "rainbow books" on computer security, from http://www.radium.ncsc.mil/tpep/library/rainbow/. I don't recall seeing an explicit copyright statement, but government documents on a government site should be public domain. (I can always file a FOIA :-) I would simply upload these packages, except my "new maintainer" status has become controversial and I don't have access to the upload area. I'm also looking for a distribution site which can handle a large amount of data subject to US export control; that eliminates cheap host sites and all OSS sites with automatic mirrors. A limited number of CD-R disks are available for beta testing. Preference will be given to sites running Kerberos (typically, large universities and some cable modem systems). I'll also send one to anyone (modulo below) for the price of materials and postage; call it $5.00. Due to export regulations, I can only ship the disks to US and Canadian residents. I also need your e-mail to state that you do not intend to export it in violation of US or Canadian law. I agree the law is stupid and grossly misguided, but I'm still working to change the system from within. Bear Giles [EMAIL PROTECTED] --------------------- [1] For the record, I highly value "fairness." In the past, some of my employers have tried to claim that *any* code I work on at *any* time and under *any* circumstances is their property. I told them to take a flying leap. I've had universities tell me that all code developed for classes was their property... and as a graduate student we weren't always talking about trivial programs. I said no way, gave them a theoretical question involving research motivated by a real world problem faced by my employer, then did all of my work on my own hardware. I firmly believe the same thing applies with volunteer efforts. When I'm volunteering work for Debian, it can set reasonable restrictions on what it will accept. It can tell me that all contributions must be open sourced. It can tell me that it can't accept non-exportable software. It can limit the type of work I do with computers or bandwidth provided by them. It *can't* tell me that I can't own any system with Microsoft Windows on it, or work for a company that uses proprietary software, or (God forbid), actually make my living writing non-open source software. The mere fact that I'm volunteering my time to help OSS, instead of passively accepting the work of others, should be the sum total of ideological litmus tests required! Finally, the "commercial use" I can forsee for these packages is not in the SOHO market. It's acting as a outside consultant on tying Linux servers into an existing network with minimal disruption. The software is free. My advice is not, and these companies can legitimately ask that any derived works remain their property. --------------------- Secure Linux -- kernel patch ------------------------------ ========== Overview ========== This patch is a collection of security improvements for the Linux kernel, all configurable via the new 'Security options' configuration section. Non-executable user stack area -------------------------------- Most buffer overflow exploits are based on overwriting a function's return address on the stack to point to some arbitrary code, which is also put onto the stack. If the stack area is non-executable, buffer overflow vulnerabilities become harder to exploit. Another way to exploit a buffer overflow is to point the return address to a function in libc, usually system(). This patch also changes the default address that shared libraries are mmap()ed at to make it always contain a zero byte. This makes it impossible to specify any more data (parameters to the function, or more copies of the return address when filling with a pattern) in an exploit that has to do with ASCIIZ strings (this is the case for most buffer overflow vulnerabilities). However, note that this patch is by no means a complete solution, it just adds an extra layer of security. Many buffer overflow vulnerabilities will still remain exploitable a more complicated way. The reason for using such a patch is to protect against some of the buffer overflow vulnerabilities that are yet unknown. Also, note that some buffer overflows can be used for denial of service attacks (usually in non-respawning daemons and network clients). A patch like this cannot do anything against that. So I suggest to use the patch, but fix vulnerabilities anyway as soon as they become known. Restricted links in /tmp -------------------------- I've also added a link-in-/tmp security fix, originally by Andrew Tridgell. I changed it to prevent from using hard links too, by not allowing non-root users to create hard links to files they don't own. This seems to be the desired behavior anyway, since otherwise users couldn't remove such links they just created in a +t directory. I also added exploit attempt logging. Restricted pipes in /tmp -------------------------- In addition to restricting links, you might also want to restrict pipes to make data spoofing attacks (like the GCC virus) harder. Enabling this option disallows writing to pipes not owned by the user in +t directories, unless the pipe is owned by root. Restricted /proc ------------------ This was originally a patch by route that only changed the permissions on some directories in /proc, so you had to be root to access them. Then there were some more very similar patches by other people. I found them all quite unusable for my purposes, on a system where I wanted several admins to be able to see all the processes, etc, without having to su root each time. So I had to create my own patch that I include here. This option restricts the permissions on /proc so that non-root users can see their own processes only, and nothing about active network connections, unless they're in a special group. This group's id is specified via the gid= mount option, and is 0 by default. (Note: if you're using identd, you will need to edit the inetd.conf line to run identd as this special group.) Also, this disables dmesg(8) for non-root users. You might want to use this on an ISP shell server where privacy is an issue. When using this part of the patch, most programs (ps, top, who) work as desired -- they only show the processes of this user (unless root or in the special group), and don't complain they can't access others. However, there's a known problem with some versions of w(1), which only show this user when they can't get the command line of others. The workaround is to use who(1) instead, or install a version of w(1) that doesn't have the problem (old Slackware 3.1's works just fine: shows other users too, but without their commands). ================ How to install ================ Apply the patch. In kernel configuration, go to the new 'Security options' section. Read help for the suboptions, and configure them. If desired, edit /etc/fstab to specify the group id for /proc. Build the kernel and reboot. You may also want to add the following line to your /etc/syslog.conf to log [security] alerts separately: kern.alert /var/log/alert Additionally, you may do something like this (assuming the log file will be empty most of the time): > /var/log/alert chown root.staff /var/log/alert chmod 640 /var/log/alert echo "more /var/log/alert" >> ~your_usual_non-root_account/.bash_profile chattr +a /var/log/alert [ The last command doesn't do much unless you raise your securelevel, for example, with securelevel.c supplied with this patch. ] Ensure that the non-executable stack part of the patch is working correctly, use stacktest.c for that -- running './stacktest -e' should segfault, and a message about possible buffer overflow exploit attempt should get logged to /var/log/alert (with syslogd configuration described above). If you enabled the GCC trampolines autodetection, try running './stacktest -t', it should succeed. If you have trampoline call emulation enabled, you can also try './stacktest -b', the exploit attempt should fail even after a trampoline call in the same process. Also, check the address libc is mmap()ed at: its most significant byte should be zero instead of 0x40 like it was before. Use a command like this: strace /bin/ls 2>&1 | grep mmap\[^\|\]\*\|PROT_EXEC | sed s/\[^=\]\*=// [ Note: strace doesn't zero pad 32 bit values it prints, so output like 0x119000 means the most significant byte is zero (this value got only 6 digits, while full 32 bit numbers are 8 hexadecimal digits long). If the patch wasn't applied, the value would be 0x40009000. ] If you enabled the link-in-/tmp fix, you can also try to create a symlink in /tmp (as a non-root user) pointing to a file that user has no read access to, then switch to some other user that has the read access (for example, root) and try to read the file via the link (like, cat /tmp/link). This should fail, and a message should get logged (if enabled). Everything is similar for write access, and for symlinks to files that don't exist. Now, you can try to create a hard link as a non-root user to a file that user doesn't own. This should also fail. ======== F.A.Q. ======== Q: Will you be updating the patch for the new kernel version 2.0.x? A: Yes, I am going to update the patch for all "stable" kernels. See: http://www.false.com/security/linux/ Q: What about 2.1.x? A: Currently I have no plans of porting the patch to Linux 2.1. Q: Will GCC-compiled programs that use trampolines work with the non-exec stack part of the patch? A: Yes, read help for the 'Autodetect GCC trampolines' configuration option. Q: How do you differ a trampoline call from an exploit attempt? A: Since most buffer overflow exploits overwrite the return address, the instruction to pass control to the stack has to be a RET. With trampoline calls the instruction is a CALL. However, in some cases such trampoline autodetection can be fooled by RET'ing to a CALL instruction and making this CALL pass control onto the stack (in reality, this also requires a register to be set to the address). Again, read help for the 'Autodetect GCC trampolines' configuration option. Q: What about glibc and non-executable stack? A: You have to enable trampoline autodetection when using glibc 2.0.x, or the system won't even boot. You will likely also want to enable trampoline call emulation since some privileged processes will have to be running with executable stack if you don't. Let's hope glibc gets fixed not to use trampolines some day. Q: What is chstk.c for? A: The patch adds an extra flag to ELF and a.out headers, which controls whether the program will be allowed to execute code on the stack or not, and chstk.c is what you should use to manage the flag. You might find it useful if you choose to disable the GCC trampolines autodetection. BTW, setting the flag also restores the original address shared libraries are mmap()ed at, just in case some program depends on that. Q: What if an attacker uses chstk.c on a buffer overflow exploit? A: Nothing changes. It's the vulnerable program being exploited that needs executable stack, not the exploit. The attacker would need write access to this program's binary to use chstk.c successfully. Q: Do I have to reboot with an unpatched kernel to try out a new overflow exploit to see if I'm vulnerable? A: No, you can use chstk.c on the vulnerable program to temporarily allow it to execute code on the stack. Just don't forget to reset the flag back when you're done. Q: Why did you modify signal handler return code? A: Originally the kernel put some code onto the stack to return from signal handlers. Now signal handler returns are done via the GPF handler instead (an invalid magic return address is put on the stack). Q: What to do if a program needs to follow a symlink in a +t directory for its normal operation (without introducing a security hole)? A: Usually such a link needs to be created only once, so create it as root. Such links are followed even when the patch is enabled. Q: What will happen if someone does: ln -s /etc/passwd ~/link ln -s ~/link /tmp/link and the vulnerable program runs as root and writes to /tmp/link? A: The patch is not looking at the target of the symlink in /tmp, it only checks if the symlink itself is owned by the user that vulnerable program is running as, and doesn't follow the link if not (like in this example). Q: Is there some performance impact of using the patch? A: Well, normally the only thing affected is singal handler returns. I didn't want to modify the sigreturn syscall, so there is some extra code to setup its stack frame. I don't think this has a noticable effect on the performance: saved context checks and other signal handling stuff are taking much more time. Executing code on the stack was not fast anyway. Also, programs using GCC trampolines will run slower if trampoline calls are emulated. However, I don't know of any program that uses trampolines where the performance is critical (would be a stupid thing to do so anyway). Signed, Solar Designer <[EMAIL PROTECTED]>
