On Thu 15 Nov 2018 at 01:30:02 +1100, Andrew McGlashan wrote: > > > On 14/11/18 10:19 pm, Brian wrote: > > There are two situations I can think of which could lead to /etc/shadow > > becoming vulnerable: > > > > 1. The machine's administrator causes it to happen. > > 2. There is a flaw in one the OS's components. > > > > The least said about cause 1, the better. There is nothing which can be > > done here. > > > > The bug arising in 2. would soon be discovered and a fix rapidly devised > > and distributed. There is nothing much to worry about here. > > Sometimes 2 doesn't get discovered for many years.
A possibility, but remember that most security bugs are discovered proactively before there is an opportunity to exploit them. People do actively look for them and there are more goodies than baddies. In the case of someone discovering a way to take /etc/shadow, the event might not come to light for some time if exploitation is very low level and not against perceived high-value hosts. But eventually it would be noticed. And what is the value to an attacker in having /etc/shadow, assuming it can be decrypted in a sensible time frame? Remotely logging in? Surely not in these days of ssh keys? > How about: > > 3. They had physical access to the drive in question (or any backup) and > that data wasn't encrypted (LUKS for example). > [boot machine with live boot USB, mount root file system and steal the > file, remove live boot USB, allow machine to startup normally] You know what is said about physical access? This is 1. in disguise. -- Brian.
