But their most interesting attack focused on the car stereo. By adding extra code to a digital music file, they were able to turn a song burned to CD into a Trojan horse. When played on the car's stereo, this song could alter the firmware of the car's stereo system, giving attackers an entry point to change other components on the car. This type of attack could be spread on file-sharing networks without arousing suspicion, they believe. "It's hard to think of something more innocuous than a song," said Stefan Savage, a professor at the University of California.

The lack of a security mindset is what accounts for upstream ripoffs of grsec features ultimately being incomplete or improperly implemented. Code will go in following an initial interest, but no single person will stick around years later to make sure it's still correct. A prime example of this is constifying of function pointers in the kernel. While in upstream it was confined to a few struct types since 2007, it was expanded a great deal in grsec and maintained until today (I'm even nice enough to make security_ops and selinux_enable read-only under KERNEXEC). Upstream never maintained constification since the initial patchset. Occasionally I'd complain about this publicly, and a spurt of interest would follow, only to be unmaintained yet again. Often times someone would make the effort of submitting all the constifying patches from grsec only to see a fraction of them applied (with no reason for the rest to not be applied). There's no eye for consistency or quality, just the name and a facade of security.

Of course it has taken us more than 13 years to take Nmap where it is today. So even Greg [Hoglund] had to acknowledge that he and one employee couldn't outdo us in a day. So he proposes that they "take a couple of days" to write their Nmap killer :).