jc-wepcrack
jc-duration-printer
pico-wepcrack
ps3-wepcrack
pcap-wepcrypt
prism-strip
simple-replay
pcap2air
libairware
lorcon
downloads
news
Put a new releaes tarball out (3.2.0). Major new features included radiotap supprt, QoS support, and added features in pcap2air. Last Changed Rev: 281
Put a new svn tarball out (3.1.1). This major change in version number is meant to indicate the shift in focus of the dev code. The svn snapshots now are tested under 2.6.22 or later kernels, primarily using madwifi-ng and rt2570. This release adds features to pcap2air, as well as preliminary radiotap support to libairware. TODO: fix simple-replay improve radiotap support. update fuzz-e. Last Changed Rev: 247 Last Changed Date: 2007-04-08 00:26:05 +0000 (Sun, 08 Apr 2007)
Put a new release out (2.40). This release is coordinated with Joshwr1ght and Dragorns talk on Extensible 802.11 Packet Flinging happening at shmoocon this weekend. This release updates -all- Lorcon enabled code in airbase to target the frozen Lorcon API. Also included in this release is a pico-enabled jc-aircrack client. Now you can use the same pico cards/images that work with jc-wepcrack with jc-aircrack. H1kari is going to do a demo of this at shmoocon as well. For more details, check out the 2.40 changes .
Put a new release out (2.35) This one includes much improved Pico support, as well as a PS3-accelerated client for jc-wepcrack.
Glenn Fleischman over at wifinetnews got the impression from broadcom that I didn't handle this very well. I have nothing to hide. Look at the emails and zip file yourself. I opted to change the email address/name of one engineer to prevent broadcom from giving him too hard of a time. Other than that (and snipping a few emails where we are trying to push a winzip encrypted file across SMTP in thread 1) the emails are unmodified.
The first thread
In this one I try to securely send the details of the flaw to Broadcom.
They opted for winzip with a password of Broadcom, instead of PGP..
the file i sent This version is un-encrypted for your convenience.
The second thread Anyone home?
The third one Looks like the MOKB link spurred some action.
The fourth one
No really, I'd like to work on this
If anyone has Glenn's email address, let me know. I'd like to reply to his inquiries but I never actually received an email from Glenn. I'll respond to a few points below.
"Broadcom is evaluating the exploits posted to determine if they do indeed give this level of access. We do not think its likely because someone would need to know exactly what driver was in use to make a successful attack. Most likely, the system will just crash."
A good point. If an attacker chooses a driver version randomly they will likely crash the target instead of getting code execution. There are two solutions to this. One is to try to fingerprint the version remotely, possibly using jc-duration-printer
However, a more practical solution is this. The only thing in this paricular exploit that varies with the driver revision is the length of the SSID needed to overwrite EIP. There are no nasty driver-dependent return addresses. (edi conveniently points at the source address of the packet in every driver version I have tested. This is why the source address in the exploit is set to 90:e9:XX:, that's x86 assembly for NOP, relative jump, distance. The real payload is after the SSID information element, so the source address is actaully code to jump into the payload. Cool huh?)
A particularly weaponized version of this exploit would simply start with a small SSID, attempt the exploit, increase the size, and repeat. If the SSID is too small, the box will probably -not- crash, and the attacker can keep trying until it is successful. The currently released version of this exploit doesn't do this, and only targets one version of the driver because releasing a version with more targets does nothing to prove the viability of the attack.
"As usual, Ellch is saying little, and Im relying on other parties relaying his words to figure out what, precisely, he said. Typically, security researchers inform a company, leave some reasonable period, then demonstrate a flaw, often leaving the actual details out until a patch is released. The MoKB project has foresworn requiring that approach for the flaws it releases."
While the MoKB doesn't really encourage submitters to inform the vendor and wait for a patch, I did. Read the emails. I waited until I knew there was a fixed driver available, verified it fixed the problem, and then released the exploit. You're right Glenn, I'm very irresponsible.
And one more thing. Before people start going 'Wow, if he's releasing all the details on this, but not the Apple thing, surely that was fabricated'. Let's get one thing straight. This time secureworks was not involved, and this time I released everything. Put the pieces together yourself.