Thomas Ptacek | July 31st, 2005 | Filed Under: Uncategorized
If David
Endler
isn't our industry's Karl Rove, he's at least its Frank Luntz.
Lots of people will talk on mailing lists about the ethics of the
"Zero Day Initiative", whether
"publishing" to it will hurt your reputation (yes) or damage the
vulnerability research community (yes). The ZDI terms dictate that
they see your findings before naming a price. The
Terms give them the
rights to all submissions without compensation. Will they steal vulns?
(probably not). Will they withhold from competitors? Etc, etc. What fun.
You're all missing the point. Believing that TPTI is going to aggressively
exploit a position as the world's vulnerability clearinghouse is like
having believed that George Bush was going to trot out Osama bin Laden to
win the election. Even if they were capable of executing that plan (like
Bush, they aren't), they don't need to.
Here's the operative
disclosure about the program from 3Com:
3Com and TippingPoint will be protected from the
vulnerability in advance, but they will not be able to tell from the
description what the vulnerability is.
Here's what's going to happen:
"Zero Day" vulns will get names like ZDI-3920, ZDI-4031, etc.
Most of these ZDI "signatures" will be for variants of other
attacks; exploit signatures, different payloads, etc.
The "real" vulnerabilities will mostly be XSS and cgi-bin detritus.
A few times a year, TPTI will coordinate and launch a "real"
vulnerability, with fanfare and press releases.
The line between "real" and "bullshit" findings thus blurred into
illegibility, TPTI will begin press-releasing things like "472
zero-day vulnerabilities disclosed to date", and use it to claim
higher signature counts and better response times than vendors
like ISS.
In other words, the antivirus playbook.
1 Comment
Thomas Ptacek | July 31st, 2005 | Filed Under: Uncategorized
Well played, Mike Lynn.
Some simple observations about the whole thing:
Mike Lynn has Dan Geer’d. Try not to feel too much sympathy; nobody
forced him to give that talk, and it is going to do wonders for his
career.
I don’t understand the people who are criticizing ISS in all this.
Maybe they’re just typecasting. Some obvious points:
Mike Lynn’s talk was work-for-hire for ISS. If he wanted
to make the world a better place, he could have turned
down the ISS paycheck.
Nobody who has spent more than a year doing vulnerability
work believes that buffer overflows are unexploitable
anywhere, even on platforms that preemptively reboot to
avoid problems. Lynn’s talk is nice work, I enjoyed reading
the deck, but, so what? Nothing forced Lynn to give this
talk over the objection of his employer.
What the fuck do you think ISS was supposed to do? They had
a pre-existing business relationship with Cisco, their
disclosure process with Cisco was poisoned. Doing the talk
would have gotten them sued, and after Cisco’s suit was
filed, they’d have a shareholder lawsuit on their hands for
being idiots.
All the people yammering about ISS being “loyal” to Mike
Lynn seem to be arguing for a weird definition of the term
that implies that, before preventing a “researcher” from
giving a talk he really, really wants to give at Black Hat,
an employer should suck it up and:
Three words regarding Cisco’s handling of this incident: fired and
fired again, whoever coordinated the PR response to this incident. Ripping
pages out of the Black Hat book? On video tape? Threatening to sue?
Asserting that Cisco software is so bad the government needs to step in to
control the release of an exploit? For a vulnerability they fixed months ago?
Over 1000 stories, according to news.google.com. The Washington Post is using
the term Ciscogate.
Good job, guys.
No Comments
Thomas Ptacek | July 20th, 2005 | Filed Under: Uncategorized
Bob Metcalfe on the IETF:
“Back when you attended the IETF, you all looked down your noses at
the ITU (or I guess it was called CCITT at the time)—the
entrenched, corporately manipulated, corrupt, competent standards
being embodied in IT. We were the IETF—the swashbuckling,
institution-oriented, open people, the rebels. That’s changed
now. The Internet has arrived, and all of those people are now just
like ITU: IETF has become the ITU.”
I agree, of course, and to extend his remarks, I always wonder: where
do people think all those OSI people went in the mid-90s? Once CLNP
lost the battle, do you think they all just gave up and went into
banking or insurance? Standards groups attract a certain kind of
person. You know, the kind whose
names come up lots in mailing lists, but not so much in “cvs annotate”
output.
I haven’t been writing much lately for a bunch of reasons:
The latter excuse has some bearing on the IETF comments, being
security work on the IETF protocol that bear not speak it’s name. I
think I have some stuff to announce, but it’s at client discretion, so
it may take awhile.
No Comments
Thomas Ptacek | July 7th, 2005 | Filed Under: Uncategorized
As usual, Bejtlich has a good roundup of the ICMP row. If your perspective on this “announcement” is, “I didn’t know ICMP had these problems!”, then follow Bejtlich’s links.
If, like me, your perspective is “these are hacker tools from when Gopher was more popular than HTTP”, the announcements probably confuse you. So, to put it in context:
The only novel thing OpenBSD has done is to statefully process MTU ICMP messages. It’s a hack that assumes that if no ACK is seen within N milliseconds of the arrival of the ICMP message, the ICMP message was probably valid. I don’t feel good about this change: what are the semantics used to validate the TCP messages that corroborate the ICMP error?
With all the talk about “errors in the ICMP specification” (uh, no), people seem to be downplaying the fact that the
ICMP spec already protects you from this attack:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Code = 4 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused = 0 | Next-Hop MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + 64 bits of Original Datagram Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TCP and IP headers (assuming no options) are included in the ICMP message; that’s enough information to do a TCB lookup and validate the sequence numbers, changing this from an (old) “blind” attack to a (really dumb) MITM attack. Mind you, this is from Mogul and Deering’s work in 1991.
I’m also not sure about the actual code, which says:
| 1014: /*
| 1015: * If we had a pending ICMP message that
| 1016: * referres to data that have just been
| 1017: * acknowledged, disregard the recorded ICMP
| 1018: * message.
| 1019: */
| 1020: if ((tp->t_flags & TF_PMTUD_PEND) &&
| 1021: SEQ_GT(th->th_ack, tp->t_pmtud_th_seq))
| 1022: tp->t_flags &= ~TF_PMTUD_PEND;
| 1023:
Shouldn’t this be verified against the window? I guess the only consequence is that attackers can now turn path MTU discovery off remotely.
The reason this is getting publicity is (again) Cisco: it’s probable that (many versions of) IOS don’t handle this ICMP message properly. Once again, people can use it to fuck with BGP sessions and disrupt Internet routing. The news here, though, is that Cisco is vulnerable to the moral equivalent of “nuke.c”, not that someone found a new vulnerability.
Frankly, the problem is that the Internet runs off a closed-source TCP/IP stack. If IOS doesn’t validate (or refuse to process) ICMP messages, do you think they got everything else right?
1 Comment
Thomas Ptacek | July 1st, 2005 | Filed Under: Uncategorized
Via DailyDave, at SecurityLemos,
Security companies have frequently pointed to circumstantial evidence that the time between the release of a patch and the publication of an exploit has decreased. The increase in binary difference analysis could explain that trend, even though there is no evidence connecting the two. After the first papers discussing the techniques were published over a year ago, there was no large spike in attacks, said SABRE Security’s Flake.
In the end, whether better binary analysis means that more companies will inadvertently be disclosing flaws by publishing patches should not matter, Flake said.
“Many people seem to pour time into the disclosure debate that should be spent elsewhere,” he said. “It’s fruitless and boring and has been for a few years.”
Though, to be fair, Halvar, so are debates about how to handle the security of patches. Doesn’t this article miss the point somewhat? BinDiff closes the gap between machine code and source code. Patches aren’t the only, or even the best, place that that gap matters. The vendors aren’t usually the ones finding the vulnerabilities. It’s not as if patches are the primary source for black hat researchers.
1 Comment
