kerberos, encrypted file systems, secure-linux 0.6, more
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
bgiles@coyotesong.com
---------------------
[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 <solar@false.com>
Reply to: