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: