-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "C. Dominik Bodi" <[email protected]> writes:
> The update-initramfs hook script for mandos client adds several > files into the initrd that are not necessary for its operation. Yes, that is indeed a bug. Very sorry about that. We will fix this right away. > One of the files being added causes a severe security risk for other > mandos client in case the client acts as a mandos server, as well. I must confess that I do not understand how this can be the case. (I guess it would be terrible if a client would, by some mistake, be set up to be its own Mandos server, but that would never work anyway, so nobody is supposed to even *have* that configuration.) > The superfluous files can be found in > initrd_root/etc/conf/conf.d/mandos/ Yes, I see them. We'll change this now to just copy the needed files (or file, as it happens). > [...], if the mandos server package is installed on the same > computer, the /etc/mandos/mandos.conf and /etc/mandos/clients.conf > will be added to the initrd, as well. Yes. This was, of course, not intended, and we will fix it now. > The latter contains the fingerprints of other mandos clients. > If the initrd file was compromised, it would be very easy to to set > up a rogue mandos server in order to snoop the other client's disk > encryption passwords. I do not see how this would be possible. If someone got a copy of /etc/mandos/clients.conf, it would *not* get them the disk encryption passwords unless they *also* got the seckey.txt from the client. Sure, this is bad, and we will fix this right away, but I do not think this is a "root security hole". It cannot be exploited unless there is *also* a root compromise or a hardware seizure on *both* the server and the client - i.e. no worse than without disk encryption, at least. And if only *one* of the server or client is compromised, there is no problem. It is *not* possible to "snoop" a client's disk encryption password by being a "rogue" Mandos server. The Mandos server receives nothing except the client's public key, and a public key never made an attacker any happier. If you think I'm wrong, please explain in a little more detail how an attack would be constructed with this bug in place. (But I *am* fixing this bug immediately.) /Teddy Hogeborn - -- The Mandos Project http://www.fukt.bsnet.se/mandos -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkrfjQ8ACgkQOWBmT5XqI91sVQCdEAJkudrGWWjlimmELf0c/84b PIQAni0hgEHNH/IkUq4KXU1dgoxcD+09 =r57Z -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
