Category Archives: Tech

12/19/06

Libnet… dead?

Just got an email from Freshmeat saying that they’ve de-listed the libnet library from their database. Sure enough, www.packetfactory.net is offline. Anyways, I’ve emailed Mike to see what’s going on. Until then I’ve uploaded my last copy of the source code to here: libnet-1.1.3-RC-01.tar.gz

UPDATE: The email to Mike bounced and the libnet mailing list has been basically dead for over a year. Starting to smell like abandon-ware. Also, I could of sworn libnet-ng had an actual web page, but looks like that was taken offline or I was horribly confused.

12/10/06

RIAA Petitions

Currently there are two petitions going on with regards to the RIAA:

First the EFF is asking people to sign a petition to be sent to Congress to ask them to do something about the RIAA’s heavy handed tactics towards children, parents and the elderly.

The second, is the RIAA petitioning some federal judges to reduce the royalty payments they make to artists. Apparently, while they’re filing lawsuits against 12 year olds for stealing Brittney Spears from file sharing sites, the RIAA wants to lower Brittney’s royalty payments for legal downloads.

While I guess “something is better then nothing”, it sure seems rather hypocritical don’t ya think?

12/10/06

Treating users vaguely

So last night I’m playing with iDVD to make well, a DVD. So, long story short, you can choose to format your DVD for 4:3 or 16:9. I wish there was a way to gracefully support both, but that’s another rant. Anyways… so there’s this feature to show you the “safe area”, which is the area of the screen which is most likely to actually be displayed on someone’s TV; apparently iDVD isn’t a WYSIWYG tool.

Now some key things about safe area this:

  • No explaination why an NTSC formatted DVD on an NTSC screen won’t show the whole thing.
  • This is an approximation. iDVD doesn’t apparently actually know what is safe.
  • There is no hint like “after testing we found this appropriate for 90% of TV’s”, so I have no idea how accurate it really is.
  • It reduces the available screen area by like 20% WTF????
  • There’s no documentation telling you how you might go about determining the actual viewable area on a given TV.
  • Even if you figured that out on your own, you can’t adjust the safe area accordingly.

Now I suppose that if you’re using iDVD you’re not a DVD authoring or TV display area expert, hence I would appear to be iDVD’s target market. But I think this is a good case of treating your customers like idiots. I can understand hiding some advanced features by default (actually I think many applications like Word, Excel, Photoshop need an option to “Hide/Show Advanced Options”) so that non-power users aren’t overwhelmed by the vast number of options, but don’t dumb thing’s down so much that you’re only making things more confusing by your vagueness.

Of course what is most frustrating is that Apple knows what the resolution of an NTSC TV screen is… there shouldn’t be this issue in the first place. Sure, some cheaper TV’s may cut off a little at the edges, but not 20%!

12/4/06

libpcap is broken

So one of the tcpreplay users has pointed out that it sometimes it doesn’t send the entire packet. I thought this was very odd since tcpreplay is actually quite simple relatively speaking so there’s not much room for bugs like this to sneak in. After some research I figured out the problem was a broken pcap capture file.

Specifically:
The libpcap specification stores multiple instances of the packet length:

  1. Maximum stored packet size per file (snaplen)
  2. Original packet size per packet (len)
  3. Stored packet size per packet (caplen)

The issue becomes when the snaplen is less then the caplen. This shouldn’t happen, but it may due to bugs in code. The result is that the libpcap library lies and returns the lesser of the two numbers (snaplen) and truncates the packet- even though libpcap advances the file descriptor caplen bytes. This clearly violates Postel’s Law.

Of course the maximum stored packet size is rather redundant- no reason you couldn’t pick a reasonable default buffer size (say 65535 bytes) and realloc the buffer if the stored packet size is larger then that. But libpcap doesn’t do that, and doesn’t provide an API to let you know that this is happening. The result is that tcpreplay only has access to incorrect information and fails to send the entire packet.

11/9/06

Vote for your favorite DLT!

I’m currently working on the libtcpedit DLT plugin support. The major goals are:
1. Make it easy to add support for new DLT types in the future.
2. Support the top 3 or 4 most commonly used DLT types out of the box for 3.0.

With that in mind, I’m requesting people let me know what DLT types other then Ethernet they work with the most. Some DLT’s to think about are: Linux SLL (cooked socket), BSD Raw IP, NULL, FDDI, PPP, Cisco HDLC, Prisim, Aironet, IEEE802.11 and IEEE802.11 w/ radio header.

So far I’ve got votes for:
– Cisco HDLC
– Linux SLL
– “the most common WiFi DLT types under Linux” (anyone know which that might be?)

When you vote, please vote for a #1 priority, #2 priority, etc. Just rattling off a bunch of DLT’s isn’t all that useful to me.

For a full list of libpcap DLT types check here.

11/7/06

Voting 2006

So I just finished voting here in San Jose using one of those Sequoia machines (same as last year). My in person impression hasn’t improved any.

1. Having to check all your votes twice (once on the screen and again on the paper printer) is a pain in the ass. Between state, county and city offices, bonds and measures it’s not only tedious to check, but error prone- especially since I don’t memorize whom I’m going to vote for in each race.

Ironically, the sample ballot that they mailed me was much simpler to use (just connect the arrow next to what/who you want to vote for), easy to verify, count and recount. And it takes a lot less time to vote since you don’t need to double and triple check that the machine didn’t screw up.

2. More importantly though, while the poll workers try to be helpful, they’re just not trained well enough. I was appalled to over hear one worker tell another how she removed the security sticker to open up the machine to “fix it”. Now, while she probably is honest and didn’t tamper with the machine (no way for me to prove otherwise), she now has violated the trust model of the election for that machine. The issue is that by breaking the security sticker, nobody can detect if anyone else tampers with the machine.

Unsurprisingly, the poll worker thought it was perfectly OK for her to break the seal and put it back in service, because she didn’t tamper with the machine. Aren’t there enough voting machine irregularities without the poll workers contributing to the problem?

Anyways, here are two videos about what’s going on with electronic voting:
First, is the HBO documentary Hacking Democracy.
Second, is the Daily Show’s John Hodgman’s comedic take on the machines.

10/14/06

Tcpreplay progress

First the good news… I’ve upgraded Trac for the Tcpreplay website which now supports built-in spam filtering. This means I’ve opened up the ticketing system to people who haven’t yet registered an account. Hopefully people will find it easier to open tickets for bugs and feature requests.

The bad news is that rewriting the L2/DLT code is even more complicated then I originally thought. Right now I’m spending my time working on the design, trying to make sure it’s flexible and easy to extend over time. Anyways, if you’re reading this, why not go check out that ticket, read the design document (realizing it’s a work in progress) and let me know what you think?

10/13/06

Is it live or is it Memorex?

About 15 years ago an audio tape company challenged people to figure out if it was live or if it was Memorex. It seems that in the networking security space we’re at the same place, trying to figure out if live tools like Metasploit can be replaced by replay tools like tcpreplay.

Now, it would seem obvious that the answer, like most things is that “it depends”, but there seems to be people who are convinced that if it’s not live it’s not a real test.

Probably the best argument against replay tools is GIGO (garbage in, garbage out). If you don’t properly vet your test samples (often in libpcap format) then you’re going to have a bad day. Generally speaking, live tools like Metasploit are easier to validate- they either break into the target or they don’t. Replay tools don’t actually attack anything, and thereby require you to trust that the test case is correct or require you to do more strenuous validation.

The second reason which seems to come up against replay tools is that somehow it’s not really like a live test. Nobody has ever actually been able to give me a case where a libpcap capture of an exploit was different from what was actually on the wire or why resending those captured packets created any differences, but people still claim that it is. They’ve argued that replay tools don’t “emulate the state of the client and server” or that “live tools adapt to differences in the server runtime” but both these arguments miss the point. A IDS/IPS doesn’t know the state of the client or server, it only guesses at the state by watching the packets on the wire. Hence, a replay tool doesn’t need to emulate the state of the client/server, just repeat the externally visible process of those state changes. And that’s something that replay tools do very well.

So are there any advantages or situations where replay is better suited? I think so:

  1. Comparative tests. If you’re comparing two products (like two IPS’s) then it’s important to use the same test cases. Live tools, due to their dynamic nature tend to auto-magically adapt behind the scenes.
  2. Regression tests. The key behind regression tests is that they don’t change.
  3. Single solution. While tools like Metasploit provide a good framework for developing a wide range of attacks, they have a limited number of attacks. This means you often need multiple tools with different interfaces to provide the coverage you’re looking for. Replay tools like tcpreplay provide a unified and protocol/attack agnostic approach to any network based attack.
  4. Simple environment. Running live tools requires you to have a victim to attack. Often this means running VMware on a 2nd system, installing multiple operating systems and configuring countless applications to attack. Replay tools on the otherhand are virtually self-contained since they emulate both server and client side of the connection.

What do you think?

09/15/06

OpenPacket a reality?

Well looks like Richard may have actually gotten OpenPacket off the ground. A public pcap repository is something I’ve often thought about doing since starting work on tcpreplay, but I’ve never had the time.

Limited access to quality pcaps has always been a limitation for users of tcpreplay, so this project may be the perfect companion. I’ll be keeping a close eye on how it develops. Hopefully they’ll have something to look at in a few weeks.

08/8/06

Help me help you.

So here’s the deal: I don’t charge a single cent for tcpreplay regardless if you’re using it for educational or commercial use. You can even embed tcpreplay in your product and sell it, I don’t care.

I don’t charge for the docs, man pages, or FAQ even though I spend quite a bit of time trying to keep the docs up to date, accurate and useful. I’m also more then happy to provide free technical support to anyone who emails the tcpreplay-users mailing list. Having people use the list means that the questions and answers are archived for future use and it gives other people a chance to help you out. If you only email me, then only I can help you and nobody else can benifit from the answer.

I suppose there are two ways you can look at this, “something for nothing” or “you get what you pay for”; either way, it seems like a pretty good deal to me. On the other side of the coin, in the last 5 years I’ve been working on tcpreplay, I’ve gotten little fame, a few “thank you” and a DVD. Obviously, I’m not doing this for the money.

So here’s the rub, don’t get offended when I balk at giving you free, 1-on-1 support directly over email. Contrary to popular belief in the open source community, developers are not your slaves. We don’t have to give you support. We help out users because we like to and because it helps make our project better. While I’m sure some developers are more then happy to go to great lengths to help you with your problems (even when they are clearly between the chair and keyboard), you’ll have to excuse me if I’m too busy to do so. And you’ll have to excuse me if I do a poor job of explaining it for the hundredth time to someone who was too lazy to read the support page without sounding like an a**hole.

So please, please use the tcpreplay-users mailing list.