Vulnerability Development mailing list archives
Re: Apache ap_getpass vulnerability
From: "Jon Paul, Nollmann" <sinster () DARKWATER COM>
Date: Mon, 6 Nov 2000 12:35:10 -0800
Sprach "Michael H. Warfield" <mhw () WITTSEND COM>:
I will concede that there is also the problem of kmem attacks and other ways of getting to the key, if someone gets superuser access to the system and can extract key material from the running system. That's a different problem (which could STILL be addressed by a smartcard or one-way coupled systems).
It /is/ the same problem: if the (unencrypted) key is owned by root, mode 400, and is in a directory which is, along with its parents, owned by root, having any mode that disallows group or other write access, all the way up to the root of the filesystem, and there are no networked daemons running on the box that are running as root (a configuration that certainly should be de rigeur for web commerce sites -- it is for all of mine), then any attack that allows you to access the key also allows you to have local root access, and therefore allows any memory attack. (how's that for a run-on sentence?) So smartcards, "secure" databases, one-way hardware, remote decryption, challenge-response hardware, coupled-firewall doing restarts through ssh, and anything else are all false solutions: the web server needs the unencrypted private key in memory for all time (or has to be able to decrypt the key with every new connection request) and therefore the unencrypted key is always available to anyone with local root access. If the unencrypted key is sitting on the filesystem in a manner that requires local root access to read, then the security is no worse than any complex scheme that you can devise involving automatic key passing, or even an attendant who provides the key at the time of each request. In fact, the security might be better, because the alternate schemes introduce new possible avenues of attack. The only real solution is to patch your kernel so you don't have /dev/kmem, /dev/mem, /proc/<pid>/mem, /proc/kcore, memmap(), shm*(), or coredumps. And even at that I'm probably forgetting some more memory attack routes. With all that done, you can safely store whatever you want in an executable's data space, without having to worry about someone getting access to it. Oops. I missed swap partitions/files... -- Jon Paul Nollmann ne' Darren Senn sinster () balltech net Unsolicited commercial email will be archived at $1/byte/day. Congratulations FBI men: Hoover would be proud of you
Current thread:
- Re: Apache ap_getpass vulnerability, (continued)
- Re: Apache ap_getpass vulnerability Jon Paul, Nollmann (Nov 04)
- Re: Apache ap_getpass vulnerability Pavel Kankovsky (Nov 05)
- Re: Apache ap_getpass vulnerability Simon Tamás (Nov 07)
- Re: Apache ap_getpass vulnerability Peter Pentchev (Nov 05)
- Re: Apache ap_getpass vulnerability Simon Tamás (Nov 04)
- Re: Apache ap_getpass vulnerability Peter Pentchev (Nov 05)
- Re: Apache ap_getpass vulnerability Carson Gaspar (Nov 06)
- Re: Apache ap_getpass vulnerability Jon Paul, Nollmann (Nov 06)
- Re: Apache ap_getpass vulnerability Carson Gaspar (Nov 06)
- Re: Apache ap_getpass vulnerability Michael H. Warfield (Nov 07)
- Re: Apache ap_getpass vulnerability Jon Paul, Nollmann (Nov 07)
- Re: Apache ap_getpass vulnerability Lincoln Yeoh (Nov 08)
- Re: Apache ap_getpass vulnerability Bluefish (P.Magnusson) (Nov 10)
- Re: Apache ap_getpass vulnerability Bluefish (P.Magnusson) (Nov 06)