Archive for the ‘Security’ Category.

Everybody update!

WordPress logo If you’re running a [WordPress][] blog, then please go upgrade now to version 1.5.1.3. A serious security vulnerability has been found in version 1.5.1.2 “Strayhorn” which can lead to remote code execution.

Read the official announcement here.

Yet another old post…

I’ve had a post lying around here in [WordPress][] as a draft for some time now. I started writing it when I was in Wallis with Stéphanie — there her mom showed me an article about skimming. This was very interesting, for I had just heard about that in my System Security lecture…

I started writing something up on the subject, but I never got it finished — before now, so please go read about skimming. I should warn you that you might be scared by what you read :-)

Exploiting Software — How to Break Code

Exploiting Software Exploiting Software, How to Break Code. ISBN: 0201786958
by Greg Hoglund and Gary McGraw.

I’ve now read through this book, and my impression of it is mixed. The book coverered lots of new stuff for me, but I’m not entirely satisfied with the way it did that.

The book (obviously) tries to cover software exploits, and it tries to do it in great detail, using lots of code listings showing both C and assembly code. The idea of explaining how real world exploits work by referring to C and assembly code it good — I’ve seen too many books which just talks about buffer overflows in theory.

But I doubt the usefulness of many of the code listings. Several of them run over multiple pages, listing entire programs which would have had a better place on a CDROM or just online. There’s no need to include so many pages of code in a book, especially when the code is listed completely bare: typeset in Courier with no bold, italic or any other syntax highlight.

Also, a good deal of the code describes plugins and other things for the IDA Pro Disassembler, which is used throughout the book in the examples. Again, the attempt to go into detail is good, but the book shouldn’t be so focused on this one tool, IMHO.

Another way in which this book is narrow-minded is the small selection of other works referenced. The bibliography in the book is very thin: three pages with just 31 cited works. Through-out the book one finds references to “Securing Java” and “Building Secure Software” — two books by the same authors. The first couple of times one sees a reference to these books it’s okay, but in the end I was wondering if I should have bought one of those books instead, since this books keeps referring to them…

Maybe those books wouldn’t waste so much paper on screenshots? This books has lots of screenshots showing “interesting” snapshots from an attack. Such a snapshot could be a standard Windows command shell, or an xterm showing the output of uname -a and id… And it’s not only the many screenshots that take up space: at one point there’s a dependency list of 161 function names from seven DLLs with one name per line, running over more than four pages. The text then concludes that this list is interesting because it shows what scrrun.dll might be able to do on behalf of a script! One doesn’t have to fill four pages with names to say that scrrun.dll (or whatever DLLs you’re analyzing) is a valuable target.

So all in all I suggest that people take a good look at this book before buying it. I would say that it requires a solid understanding of assembly code to be really useful, and experience with the IDA Pro tool is also a good idea. I have neither, and perhaps that was why I didn’t find this book that good? Please comment if you have read it!

My first keysigning party

Click to enlarge I was to my first keysigning party today, arranged by Diana Senn in the System Security course at [ETH][]. The results so far can be seen in the graph on the right, click for a full-sized image.

The keysigning itself was quite amusing. First we each got a list with the fingerprints of all the keys involved. The list was checked by having each of us read aloud the fingerprint we had brought along. For a random guy it must have been a strange thing to witness: ten geeks each reading their string of forty hexadecimal digits aloud one after another… :-)

The fun continued with the identity check. We lined up in a row and the first guy went past us and checked our IDs along the way. That was it — everybody had proper ID and everything matched.

Coming home I signed peoples keys — if a key had multiple User IDs, then I signed each ID separately. I then sent the signatures on each User ID to the corresponding email address in encrypted mails. This ensures that my signatures wont end up on User IDs which the owner of the private key doesn’t control.

The problem is that anybody can make a user ID with, say, “Martin Geisler — mgeisler@mgeisler.net” as the user information. But if they don’t control that address, then they wont get the signatures sent to it. And if the recipient doesn’t control the secret key, then the encrypted signature is useless to him. So this step binds the email addresses to the key, and should be done if one feels paranoid — or if one want to try and be a crypto-nerd :-)

I’m finally in the strong set

When I say “I” I’m talking about my GnuPG key, which has now been included in the set of strongly connected keys. See for yourself!

My key has a mean shortest distance (MSD) of 4.9, which means that on average you have a path of length 4.9 from your key to my key, provided that your key is also part of the strongly connected set. The path is made up by signatures from key to key.

My friends Thomas and Janus are now also part of the set because of the cross-signatures we’ve made.

I hope to become even more integrated after tomorrow, for there’s going to be held a keysigning party after the System Security exercises. I think that’s a really cool idea to hold such a party in relation to such a class for it helps getting people involved with cryptography so that it’s not just something they’ve heard about — they might end up using it every day like I do.