Slashdot Mirror

Cache Missing for Fun and Profit

http://www.daemonology.net/papers/htt.pdf

My paper is available here.

Have fun reading, I'm going back to the conference.

And this isn't the first time he has come up with some interesting research that has been mentioned on Slashdot before. Sure, he seems to be a little arrogant, but with his record so far, I think he's earned the benefit of the doubt here...

This is the same guy who calculated the 1 Quadrillionth hexadigit of Pi (no, not digit. It is in base 16). His project was called PiHex. According to his currently short but illustrious trackrecord, along with this current announcement, he is destined for being a big-name IT security guru.

I have a SL-5500, and I'm tired of the bundled linux port that it came with. Is there a way of installing *BSD on this device? I know there is a depenguinator that does this for PCs....anyone tried it on a Zaurus?

create an activeX control that would format the harddrive and install linux...

Ah, the holy grail of shell-hungry Script Kiddies: the D3W1N1N4T0R!

<BSD>
As long as it runs the Depenguinator on first boot, no problem.
</BSD>

With almost ten thousand people having used FreeBSD Update to download and install binary security patches, I certainly wouldn't mind getting $1 from each user. Right now I'm averaging around $0.1 per user -- most of which came from slashdot.jp readers who don't even use FreeBSD Update, and all of which went directly into buying new hardware for building the security updates.

Then of course there's my binary diff tool, which is being used by somewhere upwards of a million people, thanks to Apple's decision to use it for reducing the size of their security updates. (Ok, technically bsdiff isn't being used by all those people; bspatch is, however.) My total income from this? $0. I haven't earned a cent.

Am I bitter about not earning any money from all this? Of course not -- if I wanted to make money, I wouldn't have been giving this work away for free in the first place. On the other hand, I certainly wouldn't mind getting some monetary return for all my work.

And that's the important point to remember here: Almost all open source developers would love to get something for their work; but if they get anything, it won't be anywhere near $1 per user.

With almost ten thousand people having used FreeBSD Update to download and install binary security patches, I certainly wouldn't mind getting $1 from each user. Right now I'm averaging around $0.1 per user -- most of which came from slashdot.jp readers who don't even use FreeBSD Update, and all of which went directly into buying new hardware for building the security updates.

Then of course there's my binary diff tool, which is being used by somewhere upwards of a million people, thanks to Apple's decision to use it for reducing the size of their security updates. (Ok, technically bsdiff isn't being used by all those people; bspatch is, however.) My total income from this? $0. I haven't earned a cent.

Am I bitter about not earning any money from all this? Of course not -- if I wanted to make money, I wouldn't have been giving this work away for free in the first place. On the other hand, I certainly wouldn't mind getting some monetary return for all my work.

And that's the important point to remember here: Almost all open source developers would love to get something for their work; but if they get anything, it won't be anywhere near $1 per user.

With almost ten thousand people having used FreeBSD Update to download and install binary security patches, I certainly wouldn't mind getting $1 from each user. Right now I'm averaging around $0.1 per user -- most of which came from slashdot.jp readers who don't even use FreeBSD Update, and all of which went directly into buying new hardware for building the security updates.

Then of course there's my binary diff tool, which is being used by somewhere upwards of a million people, thanks to Apple's decision to use it for reducing the size of their security updates. (Ok, technically bsdiff isn't being used by all those people; bspatch is, however.) My total income from this? $0. I haven't earned a cent.

Am I bitter about not earning any money from all this? Of course not -- if I wanted to make money, I wouldn't have been giving this work away for free in the first place. On the other hand, I certainly wouldn't mind getting some monetary return for all my work.

And that's the important point to remember here: Almost all open source developers would love to get something for their work; but if they get anything, it won't be anywhere near $1 per user.

This is why operating systems should use delta compression for distributing security patches. You're never going to have a perfectly secure operating system; you can, however, make sure that you can fix the security flaws before they are exploited. Put another way: Size matters!

For the record, using FreeBSD Update and my binary diff tool, downloading all existing security patches for FreeBSD 4.8 (released April 2003) only requires 568kB of files to be downloaded -- which takes under 3 minutes even with a 28.8kbps modem.

This is why operating systems should use delta compression for distributing security patches. You're never going to have a perfectly secure operating system; you can, however, make sure that you can fix the security flaws before they are exploited. Put another way: Size matters!

For the record, using FreeBSD Update and my binary diff tool, downloading all existing security patches for FreeBSD 4.8 (released April 2003) only requires 568kB of files to be downloaded -- which takes under 3 minutes even with a 28.8kbps modem.

Try these:

FreeBSD Binary Updates
http://www.daemonology.net/freebsd-update/

FreeBSD/KDE packages
http://rabarber.fruitsalad.org/

FreeBSD/GNOME packages
http://www.marcuscom.com/tinderbox/

Want more?
BPM; a graphical ports collection manager for FreeBSD
http://www.meowfishies.com/bpm.rhtml

http://www.n0dez.com/

According to the link http://www.daemonology.net/bsdiff/ you get binaries 50%-80% smaller - not 50 times smaller. Obviously 50% is still good ... :)

65 times smaller? So a patch that's normally 100k is now 1.5k?

Maybe sometimes, but I don't see that happening on average.

Look at the statistics yourself. The average patch compression ratio (ie, [size of new file] / [size of patch file]) for FreeBSD Update is 66.404 right now. (Ignore the "Speedup due to patching" line -- that includes files which were downloaded before delta compression support was added.)

In fact, my current development code produces patches around 30% smaller than that, but I haven't released it yet.

For all of those who have been complaining about the large update size (90MB for a single online system; 250MB for everything), there is good news in SP2: Future updates will be much smaller. One of the new features in WMI 3.0 (which is bundled in SP2) is Microsoft's "Binary Delta Compression".

Now, while I know how BDC works, I don't know exactly how effective Microsoft's implementation is; however, my own binary diff code is providing an average 67-fold compression for the security updates used by FreeBSD Update right now. (In fact, the security patches for any supported FreeBSD release can fit onto a floppy disk.)

Microsoft's a year behind FreeBSD here, but I sure hope everybody else isn't a year behind Microsoft... otherwise, Windows users will be downloading 100-200 kB security patches once a month while they laugh at Linux users who have to download 10 MB patches.

For all of those who have been complaining about the large update size (90MB for a single online system; 250MB for everything), there is good news in SP2: Future updates will be much smaller. One of the new features in WMI 3.0 (which is bundled in SP2) is Microsoft's "Binary Delta Compression".

Now, while I know how BDC works, I don't know exactly how effective Microsoft's implementation is; however, my own binary diff code is providing an average 67-fold compression for the security updates used by FreeBSD Update right now. (In fact, the security patches for any supported FreeBSD release can fit onto a floppy disk.)

Microsoft's a year behind FreeBSD here, but I sure hope everybody else isn't a year behind Microsoft... otherwise, Windows users will be downloading 100-200 kB security patches once a month while they laugh at Linux users who have to download 10 MB patches.

The in-beta NetBSD 2.0 will support SMP, it's probably a lot like OpenBSD since OpenBSD was a fork from NetBSD.

For instance, OpenBSD releases on a 6 month schedule, usually keeps source-based upgrades working (except in the case of binary executable format changes), and is really tilted toward improving security.

NetBSD, while also a nice OS (the first free unix w/ USB support, and had wireless going seamlessly - both release quality and stable long before LInux) it doesn't feel the same as an admin. Source updates aren't supported, you don't get everything chrooted and locked down by default, and new releases aren't tied to any schedule.

If you want SMP on BSD, FreeBSD has been there for years, and also sticks to a regular release schedule. Since it has a large community surrounding it, it also has nice things like Binary Updates

In other words, at least one hundred people were perfectly willing to shell out money -- cash, presumably -- to some random guy in front of a store, then take this guy's CD home and blindly install whatever the hell he'd given them!

In other news, over 4000 people have blindly downloaded and installed binary security patches for FreeBSD. Looking at my access logs, I see a number of .gov.uk systems, a few .af.mil systems, dozens and dozens of web hosting companies... all of whom should know better than to install arbitrary binaries signed by someone they don't know.

Now, there is one difference here: Very few people have paid me anything for FreeBSD Update. But as far as security goes... we've got our fair share of insufficiently paranoid system administrators.

Last time I checked patches where text files. So what do you mean by a binary patch?

Um, possibly something like this or this or this or this or any of the dozens of other binary diff/patch utilities?

... is FreeBSD Update. 700 lines of shell code to fetch, install, and rollback security updates to an entire operating system.

Release three patches, and QA three different things, or release 1.0.3 as a complete package, so everyone who does update now has the exact same thing?

No. Build 1.0.3. Build binary patches for each of (1.0 -> 1.0.3), (1.0.1 -> 1.0.3), (1.0.2 -> 1.0.3). Provide a simple shell script which looks at the MD5 hashes of files on disk and downloads the appropriate patch. Everyone who upgrades ends up with exactly the same files; no need to QA anything more than once.

(This assumes that you trust the binary patch tool to work properly; but you can check the MD5 hashes of the files post-patch to ensure that everything worked, and download the complete file if anything went wrong. My experience with FreeBSD Update is that around 1% of systems -- usually from AMD -- have heat-induced problems during the patching process, so at least for commodity hardware, this final verification is necessary.)

So where _is_ that patch to fix these mremap bugs?

The patch is here.

I believe the study that found that once the bug leaves the development shop to go to consumers it costs $9000 per line to fix.

That figure depends largely upon how many customers you have and how sophisticated your patch-distribution system is. In pre-internet days, a critical problem might have meant shipping a floppy disk to each of your customers (of course, this reduced the chance of problems being classified as "critical"). Now, most security problems in FreeBSD can be fixed in two minutes using 50kB of bandwidth and binary patches. Most operating systems fall somewhere in the middle, distributing entire files, or even complete packages, every time a one-line security fix is necessary, with the effect of requiring a 50-fold (or more, in the case of packages) increase in bandwidth (and, over slow connections, time).

Someone from Microsoft explained this to me as "we've got huge amounts of bandwidth, so we really don't need to save bandwidth by using patches"... it doesn't surprise me that Microsoft ignores the fact that delta compression would benefit their customers, but I expected better from Apple or the Linux community.

I'm currently disassembling a new worm which is using ICQ to spread. It downloads code from www.jokeworld.biz and www.ustrading.info.

I reported this 12 hours ago. WTF are those web sites still online?

There is a [...] utility to perform binary security updates, but it does not yet work with 5.2-RELEASE.

FreeBSD Update works with i386 FreeBSD 5.2-RELEASE. There haven't been any security fixes yet, so it doesn't do very much, but it does work.

use depenguinator

FreeBSD has binary patching as well here

Helevius
Posted from a FreeBSD 5.2 RELEASE laptop

POSIX environment... C compiler... you know, it should be possible to get my depenguinator to work here.

I'm not sure about being able to write the filesystem image to disk, Windows might not allow that.

;)

Remember, that's just the beta. The full version can be downloaded here when it is released.

I've put a static snapshot of mrtg.daemonology.net up here: http://www.daemonology.net/depenguinator/slashdott ing/

I'll update it from time to time over the next day.

This is the best story ever. We are going to be able to watch the flamefest AND his server dive into oblivion: http://mrtg.daemonology.net/

Great! Thanks CmdrTaco!

Now if you say that what I described here doesn't apply to the poster's dillema since he is only going to set up one wireless AP then you're right, it doesn't. But I just wanted to point out that if he wants to set up more than one and adminster them remotely using ssh then it might be easier to go with Linux.

Or, more usefully: FreeBSD Update, which is also in the FreeBSD ports tree (security/freebsd-update).

I've never had the honour (pain?) of being directly slashdotted, but I seem to be getting an indirect slashdotting. From the link in the middle of the article (to a very handy utility in development for performing binary security updates) I'm seeing a couple visitors per second.

Not only compiler-generated random stuff, but most likely also build dates and timestamps. The FreeBSD binary update project had to deal with these kinds of issues and have written a nice paper that discusses them (51k PDF, Google HTML version).

Most people don't want the best piece of software available for a problem. They want software which is good enough. Once they've found something which is good enough, they'll probably stay with it, even if better options become available.

To take a personal example, bsdiff is a tool for generating binary patches (in particular, for upgrading software). It is measurably and quantifiably better -- that is, it produces smaller patch files -- than any other software available, both free and commercial (eg, $2750/seat). Despite this, the only place where I'm aware of bsdiff being used is in another project of my own (FreeBSD Update). Most people found a tool which was "good enough" for their needs a long time ago, and aren't going to change now.

first, I'd love to see a distro be faster than "up2date package_name" or even "aptget package_name".

FreeBSD Update. Ok, it only upgrades the base FreeBSD install, starting at binary releases, along the security branches; but it uses binary patches to dramatically cut down on the bandwidth usage (and therefore the time used). A typical install of FreeBSD 4.7-RELEASE (released in October 2002) has 97 files totalling 36MB bytes which need to be updated for security reasons; FreeBSD Update does this while using under 1.6MB of bandwidth.

first, I'd love to see a distro be faster than "up2date package_name" or even "aptget package_name".

FreeBSD Update. Ok, it only upgrades the base FreeBSD install, starting at binary releases, along the security branches; but it uses binary patches to dramatically cut down on the bandwidth usage (and therefore the time used). A typical install of FreeBSD 4.7-RELEASE (released in October 2002) has 97 files totalling 36MB bytes which need to be updated for security reasons; FreeBSD Update does this while using under 1.6MB of bandwidth.

On a (very marginally) related note, the same applies to binary patches. When applied to two versions of the same binary, bsdiff (which can take advantage of the structure of executable files) routinely produces patches which are 5-10 times smaller than those produced by Xdelta (which can't).

In short: Executable files are far more than just streams of bytes.