Re: RFP9903: AeDebug vulnerability

From: .rain.forest.puppy. (rfpat_private)
Date: Sun Oct 03 1999 - 21:49:57 PDT

  • Next message: Dan Astoorian: "Re: [Fwd: Truth about ssh 1.2.27 vulnerabiltiy]"

    > >October is Octoberfest Advisory month: one rfp.labs release planned each week
    > >for the whole month of October!  (Now, let's see if I can pull it off....)
    >
    > IMHO, this one doesn't count.
    
    Right, see 9904.
    
    > True, but you have to get something to crash that is running as a
    > higher-level user than you are.  I understand that this may be possible,
    > but it is a precondition.
    
    Understood.  Hmm, now if we could just crash some system processes....
    
    > Yes, I pointed out the same thing in June, 1998.  See
    
    I wasn't aware it was you.  Mnemonix pointed it out June, 1998, and Russ
    Cooper confirmed.  But I'm sure you were closely involved in the
    discussion.  See 'my bad' in 9904.
    
    > Nope.  This is NOT default.  There is some strange condition involving
    > upgrades from specific versions of NT.  My own workstation had allowed
    
    Ok, willing to detract default.  I will only inject personal experience,
    which consists of viewing (counting...) 16 NT server installs (SP 3 to SP
    5 level), and verifying with other people (who had the same permissions).
    So not default, I guess not on workstation, but damn, it does seem to be
    abound.
    
    > A further precondition for pulling this off is that you need to be able to
    > place a binary on the system.  Else changing the registry key gets you
    > nowhere.
    
    If you can run programs, you can (attempt) to use ftp or rcp to pull files
    in.  I realize this is dependant on outgoing firewall rules, access to the
    commands, etc.  But it's not impossible--these methods have been used by
    many people contacting me on the RDS issue.
    
    > Nope.  Not unless the process that is getting debugged is running with a
    > higher privilege level than a normal user.  You might want to test some of
    
    As a side note, is there some SeDebug or somesuch privilege?  I have
    deja-vu in recalling it....
    
    > higher privilege level than a normal user.  You might want to test some of
    > these theories before sticking them in advisories...  Consider that the
    
    Ouch.  Ok, right...test theories before sticking them in advisories.
    Hmmm, all 16 NT servers, plus my friends who were kind enough to help
    confirm (greets to NMRC), all saw it.  And great, problems *like* this was
    discussed back in 1997, and Mnemonix (and you) posted this exact problem
    in 1998.  Why the hell is it still an issue at the end of 1999?
    
    > 1) Find a machine with 139 listening
    
    This is typically an issue when attacking remotely through the internet.
    However, this seems to dissolve when you have internal access (inside
    job).  Check out the numbers for the 1999 CSI-FBI incident survey,
    regarding internal security problems at www.gocsi.com/summary.htm
    
    > 3) See if that particular machine allows rights to AeDebug (most don't)
    
    Accept, amazingly, mine (of course).
    
    > 5) Make something crash that has higher access rights than you do
    
    It's NT.  That mean the odds of a blue screen within 2 weeks is pretty
    good. :)
    
    > Actually, June 1998, but whatever.
    
    Hmmm,...you talk about adding checks to ISS scanner 4.3 back on April 19,
    1997 for basically this problem in general.
    
    > Yes, there's even a document entitled "Securing Windows NT Installation" on
    > Microsoft's site, and it has been there for quite some time.  It recommends
    > checking the security on this particular key, as well as several others.
    > Steve Sutton's NSA paper mentions it as well.  So does the ISS Scanner
    > documentation.
    
    Forgive me for thinking that all needed security fixes are handled by
    upgrades, hotfixes, and service packs.  Plus, you need to keep track of
    the oh-so-well-organized MS KB and ever-evolving documents for *extra*
    security fixes not included in the upgrades, hotfixes, service packs, etc.
    
    > unless registry security in this area has been closely examined.  BTW, that
    > one's been known since 1996, so no advisory is needed.
    
    DAMN!  How will I be able to make 5 releases in Oct when you keep stealing
    all my ideas?  I'll just have to get more creative...maybe I'll go through
    the 1994 archives.  I can see it now:  RFP9905 -- problems with
    /cgi-bin/phf.
    
    > Gee - I thought making an advisory out of something over a year old _was_
    > humor!
    
    Right.  It is, if you look at it in the right way.  You seem to be
    laughing.  I'm sure others are too (Russ?  Did you laugh?  Even a
    little?).  I'm laughing purely at the degree you seemed to hop onto my
    case.  Yes, I released an advisory on AeDebug.  Stupid me actually had
    deja-vu of the word 'AeDebug', which should have been forewarning that I
    read about it already (which I did).
    
    But damn, with all the security problems in NT, who can keep track?
    
    .r.f.p.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:06:33 PDT