And the guy who did this says that someone at cisco called him a
terrorist, and that the IETF ignored him .. but Theo deRaadt believes
him, and puts his changes into the openbsd codebase.
All for your basic ICMP source quench / hard ICMP error exploits, from
a quick read through
http://kerneltrap.org/node/5382
Oh well, makes interesting reading if nothing else.
Are you speaking of this, or is it more vulnerability
marketing?
http://www.niscc.gov.uk/niscc/docs/al-20050412-00308.html?lang=en
- jared
This is it
And the guy who did this says that someone at cisco called him a
terrorist, and that the IETF ignored him .. but Theo deRaadt believes
him, and puts his changes into the openbsd codebase.
He doesn't say that the IETF ignored him. That's not accurate. He
clearly says that the IETF did not care. There's a difference. The
issues were not considered important enough to fix by the IETF (as
the problems lie in the basic ICMP specifications.)
As for his claims about the Cisco manager, nobody called him a
terrorist, that's outright absurd. Read more carefully. What they did was
just as absurd but more subtle. They pulled a Fox News. Fernando clearly says
that "One of Cisco's managers of PSIRT said I was cooperating with terrorists,
because a terrorist could have gotten the information in the paper I wrote!"
He also says that Cisco claimed patent rights on solutions to
the exploits. This isn't made up. Ask him for the email thread
with Cisco (or ask David Miller for that matter.)
Suresh, there's no reason to attempt to paint Fernando as a frigne loon.
In reality these ideas are just basic common sense, even more so as some
of these exploits are obviously well known yet none are widely solved.
Unfortunately several people replying to this article in various places
are already confusing sequence number tracking in TCP with the idea
of using the TCP sequence number in the ICMP error packet to track
its legitimacy. That is 1. Not implemented anywhere since 2. To be useful
it would need to come from an IETF standard that everyone implements in
the next Windows hotfix, Linux kernel version, *BSD kernel, etc. It would
make ICMP error messages just as hard to spoof as TCP RST packets themselves,
and finally say you were a host that implemented this newer IETF ICMP
standard, you could just ignore (soft reset) packets from hosts with
no sequence number, while you do the correct hard reset for packets from
other hosts which are up to date.
All for your basic ICMP source quench / hard ICMP error exploits, from
a quick read through
What is interesting about the article are the simple solutions for these
exploits. While the fixes may seem trivial, that's all the more reason
to implement them. The idea is to basically just disable certain old ICMP
facilities that are rarely used on the modern internet. Why the
resistance to common sense ?
Some pointers to IETF threads would be great
I agree that some of these should be fixed - but jesus, they've been
around for years at least
regards
srs
Look for "" at TCPM WG archives at http://www1.ietf.org/mail-archive/web/tcpm/current/index.html
There have been multiple threads on the subject -- look for "ICMP". In the last 5 months, the following messages have generated message thread(s).
http://www1.ietf.org/mail-archive/web/tcpm/current/msg01026.html
http://www1.ietf.org/mail-archive/web/tcpm/current/msg01018.html
http://www1.ietf.org/mail-archive/web/tcpm/current/msg01066.html
http://www1.ietf.org/mail-archive/web/tcpm/current/msg01111.html
http://www1.ietf.org/mail-archive/web/tcpm/current/msg01185.html
http://www1.ietf.org/mail-archive/web/tcpm/current/msg01210.html