The word from kernel.org

[Posted October 1, 2011 by corbet]

Two messages have been sent to the linux-kernel mailing list regarding the imminent return of (parts of) kernel.org. The first describes how to re-establish credentials on the new kernel.org system; it is mostly concerned with how to use gpg to create a new key and get it signed. The first step is "make sure your systems are uncompromised", a problem which is addressed by the second message. "The compromise of kernel.org and related machines has made it clear that some developers, at least, have had their systems penetrated. As we seek to secure our infrastructure, it is imperative that nobody falls victim to the belief that it cannot happen to them. We all need to check our systems for intrusions."

The word from kernel.org

Posted Oct 1, 2011 15:15 UTC (Sat) by slashdot (guest, #22014) [Link] (12 responses)

Those steps don't guarantee anything.

Here is a much more sensible set of steps:
1. Unplug the network cable
2. If your motherboard has it, use an hardware function to restore the original BIOS from ROM
3. If not, flash the BIOS via software, and hope that isn't intercepted by the existing potentially trojaned BIOS; alternatively, replace the motherboard
4. Boot from a distribution CD burned from an uncompromised machine
5. Make a copy of all the filesystem except /home and /root
6. Remove any packages not found on the distribution CD (keep a list for later)
7. Reinstall all packages from the packages in the distribution CD
8. Make sure no non-distribution software is being set to be executed by default, or has the same name of system binaries
9. Make sure no non-reinstalled configuration file contains malicious or insecure script or executable code
10. Reboot, make sure the BIOS isn't network booting, configure the firewall to block any new incoming connection, then plug the network cable in
11. Run any checking tool you can find
12. Launch an automatic package upgrade
13. Reinstall all non-distribution software
14. Flash your BIOS to the latest version if needed
15. Fine-tune your firewall policy

The word from kernel.org

Posted Oct 1, 2011 15:18 UTC (Sat) by gregkh (subscriber, #8) [Link]

Of course these steps don't "guarantee" anything, we didn't say that.

We were just offering a list of things that can be helpful to do, if you wish to try to detect if your machines are compromised or not.

I never said, "if you do these things you are clean", as that would be folly.

Thanks for your list.

The word from kernel.org

Posted Oct 1, 2011 15:23 UTC (Sat) by slashdot (guest, #22014) [Link]

Actually, after step 7, also reinstall GRUB; if not reinstalling it to the MBR, replace the MBR as well (via install-mbr or ms-sys).

The word from kernel.org

Posted Oct 1, 2011 15:48 UTC (Sat) by welinder (guest, #4699) [Link] (7 responses)

That list is no better than the first one.

If you have an attacker with that level of sophistication (i.e.,
*they* are after you), then this is a half measure only.

You're going to have to reflash every piece of software in there,
probably including what's on the disks' control boards and the
video card(s). Maybe even the keyboard. (And if *they* had
physical access, don't bother. Just have it smashed to single
atoms.)

Every piece of software, btw., includes anything executable in
/home:

* Dot-files
* Makefiles
* Scripts
* Compiled binaries (including libraries and .o files)
* Source files that might have been trojaned
* Configuration files for, e.g., git repositories.

And what about video files? MPlayer and/or the libraries it uses
has more holes than a Swiss cheese (which is why it segfaults so
often on corrupted files). That would be a sneaky place to put
something that restores *their* control.

So /home really has to go too. Files you can inspect can be
recovered on a one-to-one basis.

Cleaning up an infected system

Posted Oct 1, 2011 15:53 UTC (Sat) by abacus (guest, #49001) [Link] (1 responses)

The approach I prefer is not to allow any inbound connections from the Internet on a kernel development system. Helps a lot to prevent infections :-)

Blocking inbound connections

Posted Oct 1, 2011 20:30 UTC (Sat) by robbe (guest, #16131) [Link]

A lot of recent high-profile breakins (Google, RSA, come to mind) were done by exploiting holes in normal client software (mostly written by Adobe -- which either speaks to its lack of quality, and/or ubiquity).

Exploiting network-facing daemons is so last century.

The word from kernel.org

Posted Oct 1, 2011 21:25 UTC (Sat) by jrn (subscriber, #64214) [Link] (3 responses)

> If you have an attacker with that level of sophistication (i.e., *they* are after you), then this is a half measure only.

Well, let's say you discover that a friend's house is bugged. You're worried that your house might be bugged, too. Do you:

A. Incinerate all your belongings, break off all relationships to previous friends, and start a new life in another country?

or:

B. Use whatever half-measures you deem appropriate to check the house for bugs (or get a new house), and then move on with your life?

The word from kernel.org

Posted Oct 3, 2011 5:09 UTC (Mon) by jcm (subscriber, #18262) [Link] (2 responses)

Dude, you forgot the bit about fingerprints. You totally need to have your fingerprints surgically removed, then have facial reconstruction surgery to make sure "they" can't find you ;)

The moral of this little story is we can all go batsh*t crazy and take this as far as we like, but in the end the only secure thing is to just go in a hole somewhere without network access. Failing that, plan for when you will be rooted the next time.

The word from kernel.org

Posted Oct 3, 2011 8:11 UTC (Mon) by jezuch (subscriber, #52988) [Link] (1 responses)

> The moral of this little story is we can all go batsh*t crazy and take this as far as we like, but in the end the only secure thing is to just go in a hole somewhere without network access.

Ah, the "Press Enter" scenario. But no network access is not enough. Remember the pipes.

The word from kernel.org

Posted Oct 3, 2011 8:37 UTC (Mon) by GhePeU (subscriber, #56133) [Link]

> The moral of this little story is we can all go batsh*t crazy and take this as far as we like, but in the end the only secure thing is to just go in a hole somewhere without network access.

<cryptonomicon>You forgot Van Eck phreaking.</cryptonomicon>

The word from kernel.org

Posted Oct 2, 2011 16:39 UTC (Sun) by lkundrak (subscriber, #43452) [Link]

The keyboard firmware exploit is not only theoretical, at least on Apple Computers: http://semiaccurate.com/2009/07/31/apple-keyboard-firmwar...

The word from kernel.org

Posted Oct 1, 2011 17:47 UTC (Sat) by dashesy (guest, #74652) [Link]

"4. Boot from a distribution CD burned from an uncompromised machine"

These instructions are recursively infinite, they rely on the existence of another uncompromised machine, that need to be validated with the same steps.

The word from kernel.org

Posted Oct 3, 2011 10:57 UTC (Mon) by yoshi314 (guest, #36190) [Link]

given the time and amount of work involved "get a new computer" sounds fairly reasonable, if you've got a tight deadline.

not that i condone that kind of a solution, though.

The word from kernel.org

Posted Oct 1, 2011 18:33 UTC (Sat) by josh (subscriber, #17465) [Link]

These steps seem to assume the developer currently has a compromised key, except that they then later talk about "If you are reasonably certain that your old key has never been jeopardized", which doesn't seem to make sense given the previous comment about creating a new key. What procedure should a developer follow to continue using their existing, uncompromised GPG key?