From: pauls at utdallas.edu (Schmehl, Paul L)
Subject: No Subject (re: openssh exploit code?)

> -----Original Message-----
> From: mitch_hurrison@...lip.com [mailto:mitch_hurrison@...lip.com] 
> Sent: Tuesday, October 21, 2003 12:18 PM
> To: Schmehl, Paul L
> Cc: full-disclosure@...ts.netsys.com
> Subject: RE: [Full-Disclosure] No Subject (re: openssh exploit code?)
> 
> I've said all along that this issue has been publicly 
> recognised as being a security issue from the getgo. Besides 
> my personal beliefs that has been the main fuel behind my 
> arguments against exploit or practical exploit methodology 
> disclosure for an issue that is potentially devastating.
> 
There are varying degrees of "devastating", Mitch.  Code Red attacked
IIS servers, which was a limited number of machines in most
environments.  And the end result was a defaced website.  Not pretty,
but not particularly devastating either.  (And yes, I know about the
renamed command interpreter and the implications of that.)

SQL Slammer attacked even fewer machines than Code Red, but its impact
on networks was much greater.  Blaster/Welchia attacked every unpatched
MS 2000 and XP machine, *but* the traffic impact was negligible (at
least it was from our perspective.)  So, we chose here to forgo scanning
for unpatched machines and simply take them off the network when they
got infected.  (Everything in life is a trade-off - in this case time
spent scanning for unpatched machines versus time spent detecting
infected machines and notifying the owners.)

Admins and management base decisions on those differences.  Now let's
look at the case at hand, which you characterize as "devastating".
> 
> Let me quote from CERT Advisory CA-2003-24:
> 
> "There is a remotely exploitable vulnerability in a general 
> buffer management function in versions of OpenSSH prior to 
> 3.7.1. This may allow a remote attacker to corrupt heap 
> memory which could cause a denial-of-service condition. It 
> may also be possible for an attacker to execute arbitrary code."
>
Note the words "may......cause a denial-of-service condition"  and
"may.....execute arbitrary code".  It is those vagaries that folks who
run large networks need clarified.  If something *may* cause a problem,
the correct preventative action could be entirely different from
something that *will* cause a problem.  Decisions about whether or not
to take critical services offline **right now** for patching are
*frequently* based on those nuances in wording.
 
> And allthough I hate to quote the childmolestors at CERT on 
> anything, it would seem to me that a CERT bulletin, which 
> indicates the likely exploitability, of this issue is all
> the official leverage an admin would need to convince 
> management of the need to patch no? 
> 
First of all, I object to your characterization of an entire
organization based on the *alleged* actions of one individual.  And I
would ask you to ask yourself, *why* do you feel the need to make such
statements?

As I've pointed out above, that bulletin is *not* sufficient leverage to
take major services offline *outside* a normal maintenance window.  Now
mind you, we're really picking nits here.  I suspect most organizations,
as have we, have already patched for this particular problem.  But my
point is, networks make decisions about *emergency* patching based on
the severity of reports.  Words like "may" and "could be" and "looks
like" don't indicate an emergency situation.

When the RPC stuff came out, there was an immediate recognition by the
admins that I know that it was severe and required immediate action.
Exploits didn't come out for another two weeks, and it took another two
weeks after that for the worm to be released.  But we were ramped up in
full emergency mode by late September.  And I know many others that were
as well.

> So with that base covered, why is there still a need for 
> admins to hunt exploit code on public forums, unwittingly 
> shouting "look world, I haven't patched any mission critical 
> systems on my network yet". It's a sad state of affairs when 
> admins are forced to seek out proof beyond the bulletins of 
> an officially recognised source of security alerts such as 
> CERT, before given the green light for downtime. 
> 
Well, hopefully what I've written above will clarify it for you.  I
suspect that most of the discussion on this issue that's taken place in
the past few days is rather academic.  I doubt there's many networks
that haven't already patched ssh everywhere they have it.  Now people
are wanting to understand the theory because its impact could be much
larger than this single issue.  As you should be aware, there are
obviously competent programmers who didn't realize (or didn't agree)
that heap exploits could lead to root compromises.  This appears to be
an area that needs more research and publicity.

> So I fail to see why you, or any admin for that matter. Would 
> need go on "what mitch says" in the first place. My intention 
> was to make a point about people taking exploits and the 
> theory behind exploitation as a given. They see it as a 
> commodity not recognising the hard work people put into the 
> research involved.
>
Oh.  I missed that point entirely.  Personally I recognize the hard
work, and I'm not sure the situation is as bleak as you appear to think
that it is.
 
> Secondly I wanted to make people think about the "need" for 
> an exploit. First of all we have CERT issueing an official 
> bulletin providing every admin in the world with the leverage 
> they need to justify downtime.

Speaking for myself only, I never check CERT.  By the time they publish
something it's usually way past the point that I should know about it
and have already acted on that knowledge.  I suppose there are others
who value CERT's advisories.

> Secondly all the bugdetails 
> and the impact of the bug have been recognised.

>From your perspective, perhaps.  From the perspective of the average
admin, everything that's been discussed so far is theoretical.  "May be"
a DoS and "may be" exploitable is far from, "is" exploitable.  Keep in
mind, we're discussing this from the standpoint of someone who has to
decide if they should take a critical server down for patching *now* or
wait until the regularly scheduled maintenance window - *not* should I
patch?  Or not?

> What remains 
> is the actual practical, public, exploitation of the problem. 
> The theory of which is readily available for anyone willing to put in
the time. 
> 
Really?  Perhaps you could provide the list with some links then?  To
the theory?  It seems that Frank, who obviously understands the issue
pretty well, had not thought of the issue from the perspective that you
had, and when you gave a few pointers, it was enough for him to put the
pieces together.  I'm sure there are others who would also need that
extra hint to put the pieces together.  You could certainly do that
without violating your desire to not release an exploit, couldn't you?

> So, allthough I must say I was pleasantly surprised to see 
> you make an effort at normal debate, I still believe none of 
> your arguments apply to this case. Admins shouldn't try to be 
> hackers and I think you'll agree that most hackers shouldn't 
> try to be admins.
> 
I don't think admins *are* trying to be hackers.  They're trying to
balance what little precious time they have against the need to disrupt
normal work flow for an emergency patching session.  And at this point
in this particular issue, I suspect much of it is just pure curiosity.
I'd take a poll, but I doubt anyone would admit to not having patched,
so it would be rather useless data.  But I suspect the number who have
patched already would be rather high.

> With that solved, I dare to hold to my earlier statement
> that there is no need for this exploit to be disclosed. Nor
> is there a need for the practical methodology behind the 
> exploit to be disclosed. There is however, a need for people 
> who regard the research of others as a commodity that is 
> theirs for the taking, to rethink their outlook on life.
> 
Perhaps you'd like to elaborate on this?  I'm not sure I fully
understand the nature of your complaint.  Nor have you really offered
any suggestions for correcting the issue.

Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/~pauls/ 

Powered by blists - more mailing lists