Message-ID: <Pine.GSO.4.58.0507211223230.3764@well.com>
Date: Thu, 21 Jul 2005 14:26:04 -0700 (PDT)
From: Vic Vandal <vvandal@...l.com>
To: Fernando Gont <fernando@....utn.edu.ar>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	Markus Friedl <markus@...nbsd.org>, Theo de Raadt <deraadt@....openbsd.org>
Subject: Re: ICMP Security Vulnerabilities - NEW  (cough)


Dude, I'll try to respond to what you're saying, but I avoid
these mailing lists because I simply don't have time to deal
with such things (hence my delayed response).  I'm a VERY busy
person, and my life/interests don't revolve around IT/InfoSec.
It's simply a "job", which I do well and have done much better
than most for more years than most.

First, I've got no beef with you, and I truly respect what you're
trying to do.  It's the huge glut of daily "discovered vulnerabilities"
that has long bugged me, in the sheer fact that MANY are neither
"newly discovered" nor are "actual vulnerabilities".
If I tried to comment on each daily, I would have no time in my
life for anything else whatsoever.  So obviously I won't EVER be
doing that.  I work to live, not vice-versa.

For the record, Vic isn't my real name (it's an old band/stage
name) and isn't the only alias I've ever used.  Even where my
real name is concerned, I've seen that there is someone else
who has only been in InfoSec ~5 years who has posted questions
publicly that I wouldn't have needed to ask.  I've wondered how
many see that and think I posted such things.  But I believe he
is from the UK, and I'm from New Orleans Louisiana.

The week I posted my ICMP comments, a guy who works for me on my
security team sent me a couple articles and asked for my feedback.
He often does, as he's trying to learn things and match his
perspective against mine a bit.  Yours was one of them, and the
other was so retarded and wrong that I brushed it aside without a
second of consideration.
Anyway after we tossed comments back and forth, he pointed out
the fact that I NEVER share information/knowledge that might be
useful to others in the public domain.  And he's absolutely right.
I've given dozens and dozens of talks at conferences, but many of
those "back in the day" were done on transparency pages, white
boards, etc. (like at CA-World 5 years in a row under my real name),
or were given at "private Cons".  I've also done hundreds of
"internal white papers, technical bulletins, etc" - none of which
has ever seen the "public light of day".  Then much of my work is
"owned" by the federal government or military, and can't ever be
shared publicly.

[readers]So what's your stupid point already Vic?
Sorry...I'm getting to it.  So with this dude bending my ear, and
me thinking how true it is that I've shared so little experience,
and me considering walking away from IT/InfoSec soon to work on
other interests/projects, I decide "I'm gonna force myself to TRY
to share some information".  So I take the more interesting of the
two sent (yours), and post some old data of mine that was somewhat
handy.

Your response (and my response to it) follows:


On Thu, 14 Jul 2005, Fernando Gont wrote:

> At 06:42 p.m. 12/07/2005, Vic Vandal wrote:
>
> Vic,
>
> I'd like to sum-up my response, before quoting your e-mail to respond to
> each of your comments.
>
> a) Discussing an issue "in various circles" is not "raising awareness". The
> proof of that is the large number of vulnerable implementations, as listed
> in NISCC's and CERT/CC's vulnerability advisories.

Vic:
When I said "discussed in various circles", obviously there was
some public documentation of such things, which is what I drew
my ICMP filtering guide from so long ago.

I agree that there are a large number of vulnerable implementations
of "everything under the Sun", which is why I'm thoroughly bored
and quite sick of this profession.  It will get MUCH worse before
it ever gets better (if ever).  I applaud those who wish to "fight
that fight", but I'm hoping to go off and work on things I find
much more interesting/challenging soon.  There aren't many systems/
networks I can't break nor fix, hence "time" is the limiting factor
and the time I'm willing to put into that "fight" is nearing its
end.

>
> b) Guides and papers such as yours have broken the Internet, particulary,
> the PMTUD mechanism. Your guide recommend to filter ICMP "fragmentation
> needed and DF bit set". Thus, any intermmediate system that (unfortunately)
> implements your proposal will break the PMTUD mechanism, and thus any
> connection using it will stall (except in specific scenarios in which the
> PMTU is the same as the MTU of your link).
> I don't know if it's just that the work you read was bullshit (or too old),
> that you didn't read it well, or that you didn't care.
> Publishing non-elaborated work such as yours make more harm than good.

Vic:
It was never intended to be used in "intermediary devices" per-se,
and has never "broken the Internet" (which even you must admit was
an ignorant statement to make) or any other network in any fashion,
as "I've" implemented such things.  And I've built/administered
hundreds of firewalls for various federal government and military
entities, with no "complaints/issues" whatsoever.
As far as MTU issues go, I've seen some of that tied to and quite
independent of any network firewall.  And many network environments
are quite unique/specialized.  I assume any intelligent network or
security engineer understands their particular environment and will
know what works and what doesn't for it.  That's what "testing" is
for, after all.

>
> c) Regarding the contents of the guide itself, I'll makesome comments:
> c1) Even when your guide is about ICMP filtering, you never mention that of
> egress filtering based on the ICMP payload (read my draft on this).

Vic:
You obviously don't know the meaning of words you're using.  "Egress"
means "outbound", and the guide discusses "outbound" filtering.  So
your statement/argument is without basis/fact.
IF you're referring to some anti-spoofing filtering for egress (or
ingress) traffic, the guide wasn't about that topic and such filters
apply to all other protocols (not just ICMP).

> c2) You don't provide references. Who should I blame for your guide
> advising to break PMTUD? Only you? You and your references?

Vic:
I thought I was clear on WHY I provided no references - because I
don't have time to dig through boxes of material.  Blame?  There's
no one to be "blamed" for anything.  But if you feel like you want
to spread some personal misguided blame on someone, I could care
less if you want to consider that target to be me.

> c3) You don't provide a rationale for your proposals. Why should people
> trust you blindly? I hope (but unfortunately don't believe) nobody
> implements policies and rules they don't understand.

Vic:
The text is a "guide", as are ALL "guides", which may not apply
in individual network situations.  The fact that you don't seem
to understand that basic concept is certainly interesting.

There are implementation details missing from the guide, but that
was intentional - as different filtering products have different
syntax, features, and layers of granularity available.  It assumes
one understands the product one is working with and how to apply
the guide to their individual situation.

I never said anyone should "trust me blindly".  That's is a retarded
statement with no basis/fact.

>
>
>
> >1) Regarding ONLY the "source quench" discussion there, that is
> >   absolutely "nothing new".  I've had a paper/guide mentioning it
> >   specifically since 1994, that I've shared with various entities
> >   I've worked for since that time.  That same paper was posted to
> >   some BSD-related mailing list back in 1997 or 1998 (by a friend
> >   of mine who I had shared it with), but I can't recall the list/site
> >   name.  I've also provided it to various friends in the InfoSec
> >   industry (as recommended ICMP filtering guidance) sporadically
> >   through the years.  Yes I know Fernando's paper elaborated a bit
> >   on potential fixes, but regarding ONLY the "source quench" item
> >   again it is not "new" and has been discussed in various circles
> >   in the past.
>
> The attack is not new. The counter-measures (having TCP ignore them,
> perform ICMP egress-filtering based on the ICMP payload) and the rationale
> for them *are*, or at least, not easily available.

Vic:
Here I agree, for the most part.

>
>
> >3) I didn't "discover" the "source quench" nor any other ICMP
> >   "vulnerability", but took the work of others to provide some
> >   guidance on firewall filtering.  I wish I could give exact
> >   credit where credit is due, but don't have that kind of free
> >   time to dig through my boxes upon boxes of printed and digital
> >   resources.  Also the pointers in my mind to such details (stored
> >   a decade or more ago) have been broken somewhere in time passed.
> >   I will acknowledge that the first "widely published" discussion
> >   on the exact topic of ICMP filtering was "probably" in the 1995
> >   release of "Building Internet Firewalls" (by Chapman and Zwicky).
> >   I had the book in my desk back then, but left it behind when I
> >   left the organization that paid for it.  IF I still had it, I'd
> >   gladly quote it directly to verify the exact verbiage/discussion
> >   of the topic therein.
>
> Some other full-disclosure has the edition of 2000, and he says (and quoted
> the book) that the book advises to *allow* it.
> In any case, one of the counter-measures proposed in my draft has to do
> with TCP itself, rather with firewalls. And the one that has t do with
> firewalls is not mentioned elsewhere.

Vic:
As noted at the start of this response, I respect what you're trying
to do.  I don't respect some of your responses to me, but I applaud
the work you put into your draft nonetheless.

>
>
> >4) For future reference, I'll share the ICMP filtering guidance
> >   here (mentioned in item #1 above).  Perhaps it will help someone
> >   secure their environment, and possibly discount some "newly"
> >   discovered vulnerabilities as "old news" in the future (which I
> >   suspect some jackasses will start posting a few of these as their
> >   own "discoveries" shortly).
>
> Please don't distribute your guide. Not without this e-mail, alarming the
> sysadmin how he will DoS himself with your recommendations.

Vic:
As noted above, I've never DoS'ed myself or any entity I've ever
worked for in the hundreds of times I've implemented such things.
Your statement is without basis/fact.

>
>
> >5) Noting #4 above, this information may be re-published/distributed
> >   ONLY with the ENTIRE contents of this e-mail/posting (including
> >   these numbered statements/disclaimers).
>
> If you have this guide available at some web site, please provide a link.
> I'd like to include a pointer to it in my draft. All the people dealing
> with ICMP-blackholes will probably want to do the same.

Vic:
My personal pages aren't something I want everyone who reads full
disclosure (or even your paper) to visit, for various reasons.
If you want to post it with all my comments as stipulated in that
original post, that approval was given in that posting.  If not,
c'est la vie!

>
>
> >6) No I haven't notified "CERT", "Micro$oft", or any other
> >   vendor/organization.  This is "old news" after all, and I
> >   assume "being able to read" is a prerequisite for becoming
> >   employed at most places dealing with such things.
>
> It's a requirement, and you didn't bother to read the PMTUD
> specification???? That's quite ironic.

Vic:
You assume you know what I haven't read, and you've wrongly
assumed/inferred much here.  Someone else did likewise in his
ignorant response, which I shall also respond to when I feel
like making the time.  His response wasn't in the thread, which
demonstrates yet more ignorance on his part.

>
>
> >Echo and Echo Reply Messages - ICMP Code Type 8
> >
> >Discussion:
> >The echo message (also called echo request) is used to check if
> >a host is up or down.  When a host receives the request, it sends
> >back an echo reply message.  These messages are usually generated
> >by the ping command, but may also be generated by a network
> >management device that is polling the nodes of a network.
> >
> >Security Issues:
> >Echo requests can be used by an outsider to map your network.
> >
> >Firewall Filtering:
> >Allow the outbound echo request and inbound echo reply.  Deny the
> >inbound echo request and outbound echo reply
>
> If you assume people will implement your recommendations, then filter both:
> ping will be useless.

Vic:
In many environments I've worked in, there was no need for ping
traffic to ever cross/route through both firewall interfaces.
But there were needs for a firewall/security/network admin to be
able to ping devices on either side from the firewall itself.
Some places such "rules" apply, and some places they don't.
As noted already, my text is simply a "guide".  How it is applied
in individual environments is up to the needs of that environment.
There is no "one size fits all" in security and/or networking in
many, many cases.  This is simply one of those many cases.

>
>
> >Destination Unreachable Message - ICMP Code Type 3
> >
> >Description:
> >These messages are generated by hosts or intermediate routers,
> >in order to notify the initiator that a session cannot be
> >established.
>
> Actually, it's during the connection-establishment that these messages can
> be useful. Have a look at http://www.gont.com.ar/drafts/tcp-soft-errors.html

Vic:
Umm, agreed (without having to look at your draft that you keep
pushing/selling).  What I posted is accurate, as is your sentence
noting where such messages can be useful.

>
>
>
> >Source Quench Message - ICMP Code Type 4
> >
> >Description:
> >This message is generated by a host or a router when it wants the
> >sender to slow down the rate it is sending packets.  The IP stack
> >passes this packet to the upper layers, and they are responsible
> >for slowing the rate down.
> >
> >Security Issues:
> >This message could be used by an attacker (probably combined with
> >IP spoofing) in order to make a very effective denial of service
> >attack.  Unfortunately it is more often a legitimate message.  If
> >filtered, problems may arise due to lost packets.
>
> You miss the point. Have a look at
> http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html for a rationale
> for ignoring ICMP Source Quench messages.

Vic:
Again pushing your paper.  Regardless again I applaud what you're
trying to do.  I didn't "miss any point" though.  I get the point.
I'm not arguing the point.
That guide I posted was last updated 10 years ago.  If I had to sit
down and re-write it today in the aftermath of ping floods, pings
of death, etc., PERHAPS a small amount of content might be modified
or explained in more detail.  But IF any content were modified, it
wouldn't be much.

>
>
>
> >Firewall Filtering:
> >Allow it to be sent and received, but log the received messages
> >for later analysis
>
> So I will not only slow down your connections, but also flood your logs.
> That's awesome.

Vic:
Now THIS is real ignorance.  Anyone who doesn't know how to manage
their logs and/or their network should not be administering any
firewalls or other network devices.  I'll assume you're a young guy
who has never managed a large enterprise network, whereas I've worked
on/designed/secured many of the largest networks in the world.  I've
known how to manage my logs and have written countless lines of code
to help with that task from the day I started doing this kind of work,
back in 1989.  I also know how to manage my authorized network sessions
quite well.

>
>
> >Time Exceeded Message - ICMP Code Type 11
> >
> >Description:
> >Time to live exceeded is generated by a router when it has to
> >forward a packet with a time to live (TTL) value of zero.  Fragment
> >reassembly time exceeded is generated by a host when it does not
> >receive all the fragments needed to reassemble a packet.
> >
> >Security Issues:
> >An attacker can use traceroute to find out which hosts are the
> >routers in your network.
> >
> >Firewall Filtering:
> >Allow this for inbound packets, so your hosts can perform error
> >recovery.  Also allow all fragment reassembly time exceeded messages
> >for outbound packets, but not the TTL exceeded messages.
>
> "Time Exceeded" messages are soft errors. You don't need them for
> fault-recovery. They are helpful for providing a more informative error
> message if the connection times out. Because of the "small world" phenoma,
> it's really unlikely you will receive one of these for anything else than
> traceroute. (Unless you're intentionally using the TTL to limit how far
> your packets can be forwarded).

Vic:
Agreed.

>
>  From one of the slides of my presentation at CanSecWest 2005:
> "I know the tendency of the human mind is to do anything rather than think,
> But mental labor is not thought, and those who have with labour acquired
> the habit of application, often find it much easier to get up a formula
> than to master a principle."
>    - James Clerk Maxwell
>
> Kindest regards,
>
> --
> Fernando Gont
> e-mail: fernando@...t.com.ar || fgont@....org
>

Yeah...whatever,
Vic

P.S. All the above aside, good luck in your future work.  Please
  note that it is HIGHLY unlikely that I will respond further to
  future messages in this thread, for reasons already provided
  (mainly time constraints) - with the exception of responding
  to the ignorant person who posted his response outside the
  thread.  I did get a couple of "blocked due to profanity"
  messages that all of your recipients were CC'ed on, but I have
  no idea if they were messages from people I know coming to my
  defense or people I don't know wanting to attack my post.
  Either way I've spent more than any time I care to on this
  topic.  However I do hope to post some of my work someday,
  before it's ALL "old news".  If you ever write a paper on how
  to stop time without having to stop myself, let me know.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists