Sunday, September 24, 2006

Porting PDB to OpenBSD Act I Scene II

The need to run Matlab necessitated bringing my PowerBook back from the land of music and sound design... So, with a fresh install of Tiger I now have a box running an OS that implements divert sockets... Getting PDB up and running while my physical layer class works on examples of free space loss (and their arithmetic skills) seems like a great way to make use of the day.

Quick and dirty process to get PDB up and running on OS X:

  • Step 0 - clean out bleeding edge cruft
Clean up the build dirs for libcii and libfmt. Build those libs from the Makefiles in their respective directories; the top level make file isn't set up to do it (yet).

  • Step 1 - rbconfig.rb is broken by default in Tiger. Fix it.
  • Step 3 - where, oh where is ruby.h?
I didn't save the output from make, but the gist of it is that with the latest Xcode and the transition to universal binaries our lib path is messed up. Ruby header files are now in universal-darwin8.0 not powerpc-darwin8.0. Just symlink it all:

ln -s /usr/lib/ruby/1.8/universal-darwin8.0/* /usr/lib/ruby/1.8/powerpc-darwin8.0/ 


Now we're ready to get to business with PDB...

The 'pdb' executable is actually a little shell script that has functions for adding/deleting ipfw divert rules and running pdb (nee iledit). I wanted to do a little simple testing with a clear text protocol so I changed the divert rules to accomodate passive FTP:

~/tools/src/pdb-0.0.1.bleeding-edge$sudo ./pdb
==> Adding ipfw divert rules...
00242 divert 4642 tcp from any to any dst-port 21 out
00243 divert 4642 tcp from any 21 to any in
==> Running pdb...
hi pdb-ruby.bundle
hi ip.bundle
(pdb) c
45 10 00 38 20 c5 40 00 E..8..@.
40 06 00 00 c0 a8 01 03 @.......
81 80 05 bf c0 60 00 15 .....`..
98 d3 dd f7 82 18 d1 3c .......<
50 18 ff ff 54 5f 00 00 P...T_..
55 53 45 52 20 61 6e 6f USER.ano
6e 79 6d 6f 75 73 0d 0a nymous..

..SNIP..

(pdb) exit
I am slain!
==> Removing ipfw divert rule...
~/tools/src/pdb-0.0.1.bleeding-edge$


Excellent! More experimenting to come... time to read some code.

Wednesday, September 13, 2006

It's all in the implementation

It all starts with Daniel Bleichenbacher's novel attack on RSA signature implementation. Here is the run down...

Start with Fun with exponents (Ben Laurie of OpenSSL)

The Tom Ptacek/Nate Lawson dynamic duo:

Other distractions:


Not crypto, but p0f was updated recently http://lcamtuf.coredump.cx/p0f.shtml. Now I know what I'm playing with after I finish the first assignment for my physical layer data-comm class. Now, back to reading about antenna design...

Reused Rants on Consultant Presentations

A perhaps hypothetical security consultant asks for suggestions concerning emerginging threats to 'Corporate Data & Privacy' along the lines of 'rootkits, trojans, et cetera'. She/He wanted ideas detailing 'interesting' tactics/malware, especially those that are particularly insidious, legitimate and hard to defend against.

I understand that these types of presentations are meant to motivate cries for help but I think that you can motivate organizations/people without sinking to detailed descriptions of impending doom. I'm not saying that people don't need to understand the risks, but we want a logical and well thought out response not panicked craven mania...

My response:

What are the goals you are trying to achieve with this presentation? A rigorously compiled taxonomy of 'bad stuff' presented to people who aren't in a position to fundamentally address said stuff is just spreading FUD.

I would say that if the audience is of the business type it is might be better to discuss the landscape surrounding adversaries and their motivations/goals; speak at a strategic level about the playing field. Organized crime, Governments, Corp. Competitors, and Bogeymen (teh terrorists!) et cetera are the 'threats' to Corporate Data & Privacy; malware and other attacks are just means. I could rattle off dozens of real tactics that are 'insidious', even before getting into the legitimate but speculative attacks. No one can effectively address every specific tactic let alone a majority, but you have to try your best to address the threats that create the most risk in your particular circumstance. In most cases this means measures that are somewhat orthogonal to those that will address specific tactics, such as rootkits or trojans, measures such as effective security architecture, risk assessment, and preemptive strikes with thermonuclear weapons.

That said, and with tongue firmly in cheek, my vote for 'emerging threats':

New ways to exploit poorly implemented software running in places that no one has realized they have poorly implemented software.

e.g. device drivers, protocol stacks (network, storage,...), network/systems management systems, every single desktop app that reads a file or data from the network...

The sub category of the above worthy of further discussion is crypto systems...

Friday, September 01, 2006

Positively Orwellian

A comment to a post on Eric Rescorla's blog reminded me about an important essay by George Orwell, Politics and the English Language, that is as appropriate now as when it was first written, maybe more.

I'm writing up a report for a client (right after I post this okay!), so I want to remember this:

A scrupulous writer, in every sentence that he writes, will ask himself at least four questions, thus: What am I trying to say? What words will express it? What image or idiom will make it clearer? Is this image fresh enough to have an effect? And he will probably ask himself two more: Could I put it more shortly? Have I said anything that is avoidably ugly?


Very important.