On Fri, Jun 28, 2002 at 02:50:17AM +0200, Paul Wouters was heard to remark:
> On Thu, 27 Jun 2002, Linas Vepstas wrote:
>
> > If properly configured, such a theoretical hack would still prevent
> > the hacker from getting at the private keys, changing (or even reading)
> > ipsec.conf, or other files on the compromised system (such as the
> > password file, or changing the dns entries).
>
> the password file, the dns entries, it's all peanuts if you already
I think that's an overstatement. Listening to some guy downloading
sales reports is not the same as '03n1ng' the box.
> have the only real treassure on the box, the ipsec.secrets. Why would
?
Its not obvious that this file would be readable. I presume that
this hypotheical pluto would:
1) read ipsec.secrets
2) drop other permissions
3) chroot
How would a hacker get the secrets?
-- can't get to /etc any more, they're chrooted.
-- can't get to /proc so can't read the core
-- maybe can cause pluto to core dump, and then gdb the core dump file
to find the secrets?
I'm not sure, I presume one would 'ulimit' the user into not
allowing core dump files to be generated.
I am not a talented hacker, so maybe there are other ways of getting
the sectrets, but I don't see how...
oh, maybe they could gdb 'attach' to a running pluto process, and
read the secrets out of ram that way? Can one block a gdb attach?
--linas
-- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas_at_linas.org> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:20:17 CEST