On 4/25/14, Chad Perrin <[email protected]> wrote: > On Mon, Apr 14, 2014 at 12:36:28AM -0500, David Noel wrote: >> Thanks. I'm happy to, and it's on my to-do list, the only problem is >> that I'm swamped with other projects and it's been sitting on that >> list for the past 2 years. It seems to be a similar problem for Colin >> and the Security Team. I'm hoping that by bringing this bug to the >> list that someone with more free time will be able to patch it. > > Would you be willing to put the time into training up someone to do that > work? I'm a bit of a fixer-upper, but I am willing and eager to > contribute. Hi Chad, sorry for the slow reply. Awesome. I'm so glad to find someone with more free time than myself. I'm absolutely willing to contribute as much knowledge as possible to anyone willing to tackle these bugs. How can I help you get started? The server-side/build code wasn't available back when I was reviewing it initially but it's all on subversion now. The build code in here: http://svnweb.freebsd.org/base/user/cperciva/. freebsd-update is here: http://svnweb.freebsd.org/base/head/usr.sbin/freebsd-update/ portsnap is here: http://svnweb.freebsd.org/base/head/usr.sbin/portsnap/ The bugs in the client-side code are fairly simple to find -- just search the code for every instance of "fetch" and follow it until the file is decompressed. Instead of decompressing then sha256 verifying files, it should sha256 verify then decompress them. A pretty simple fix. IIRC in pmirror.sh there's also the issue of files being fetched and mirrored without verification. A benefit of reworking the code is that it should speed things up -- instead of sha256 verifying each individual [decompressed] file it will only have to sha256-verify once -- on the compressed archive. From the notes I took 2 years ago (that should still be relevant today), the functions/lines of concern are: portsnap.sh: fetch_snapshot(), fetch_update(), and fetch_snapshot_verify(). pmirror.sh: 99-103, 121-125, 138-149, and 153-157 (using revision 257073). freebsd-update.sh are fetch_metadata(), fetch_files_premerge(), and fetch_files(). I think the easiest way to approach this would be to trace through the code. IIRC the portsnap system is less than 2k lines and freebsd-update is around 5k. I don't know how much RAM your brain came with but when I went through it I found it easiest to take notes on key function names as I followed the path of execution. Unless you write scripts regularly it's just large enough that you might need to take notes. But it's super clean code and really easy to follow. I was fairly new to scripting when I first started reading it but by the time I'd worked my way through it I was confident that I could patch it without too much trouble (I do also code in C/Java/etc, so that might have made it easier, but I really do think that if you can work your way through the code you'll be able to patch it without a problem). Another thing that makes this such an easy fix is that everything that needs to be done is done somewhere in the code already. You could pretty much copy and paste for the entire patch. That's all I can think of for now. Let me know if there's anything else, or if you get stuck walking through the code. -David PS: If you're debating which project to start on first I would like to make the case for freebsd-update: Granted, it's twice the side of portsnap, so it might seem more intimidating to take on first, but technically we already have a secure way to check out the ports tree (svn over http secure). So if someone was concerned about security they'd just use that alternative. Given this bug we don't however have a secure way to quickly and easily perform system updates. For the security conscious the only alternative is to manually build from source (so slow!). _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"