[Dshield] WMF - SETABORTPROC alarms

Shane.Steckelberg@k12.sd.us Shane.Steckelberg at k12.sd.us
Mon Jan 2 20:32:40 GMT 2006


I'd generally agree with those statements.  My reason for a higher
posture on this particular problem was this statement by Sunbelt
(http://sunbeltblog.blogspot.com/2005/12/new-exploit-blows-by-fully-patc
hed.html)
"Any code execution that occurs will be with SYSTEM privileges due to
the nature of the affected engine."

Although most responsible administrators would double-check this, I was
alerted to this elevated privileges issues by one of my security vendors
and although not three sources; two reputable sources seemed good
enough.  If, in fact, this can only operate with user rights I am less
concerned. Regardless of the rights it is still bothersome to me as I
would assume that many nasty self-contained processes could still
execute and either cause data damage or possibly farm information even
with those minimal rights.

I'd appreciate knowing if the elevated rights is possible without
testing myself as I am not privy to this!


-----Original Message-----
From: list-bounces at lists.dshield.org
[mailto:list-bounces at lists.dshield.org] On Behalf Of bschnzl at cotse.net
Sent: Monday, January 02, 2006 7:10 AM
To: list at lists.dshield.org
Subject: [Dshield] WMF - SETABORTPROC alarms

Folks...

   I would like to examine the relative risk involved with the WMF -
SETABORTPROC (heretofore "WMF") issue.  Setting aside responsible
disclosure issues, I believe the vulnerability is not as pressing as
others in the past.  Resources used in testing the "unofficial" patch
are better used elsewhere.  Insight from replies will guide my response
to this disclosure.

   Here is my analysis of the disclosure.  The potential for automatic
exploit is low.  If one limits user shell activity on critical machines
properly, exposure is reduced, and native recovery platforms remain
available.  The exploit renders privilege in the current security
context, requiring additional functionality to perform administrative
level functions.  As well, limiting NetBIOS connections across network
boundaries removes the largest exposure.  
Best Practices already indicate more controlled environments for Road
Warriors, increasing this risk only marginally.

   The vulnerability requires the opening of a graphic file.  This is
decidedly a user function.  Windows Explorer will do this to every file
in opened directories, but the user has to open the directory.  
Thus, the speed with which any malware will travel through a network is
reduced below that of the Nimda and Zotob worms, for instance.

   Those with access to critical machines are more likely to know that
reading your personal mail on a server is not recommended.  
While browsing the web is certainly doable on a windows server,
hopefully administrators know that is not a good idea.  Generally, these
users have better ideas of how they will do things when they start
pushing the mouse around.  With more deliberate action paths comes less
risk, in this case especially.

   This exploit compromises the user's account only.  Hopefully users
are limited in what they can do to their physical workstations.  
Certainly they should be limited to how they can make changes on the
server.  While any compromise is dangerous, real system damage requires
another attack in this case.  That gives those who practice
defense-in-depth another opportunity to detect the intrusion.  Again, it
could be worse.

   In this day and age, most of us know that allowing NetBIOS to the
open internet is asking for trouble.  In the case of a file finding its
way on to shared drive spaces still only infects the workstations that
open it.  The server that hosts that file can be cleaned from a command
line.  As well, in the case of older variants, the server provides a
second chance at detection.

   Road warriors remain a problem, but this particular issue does not
increase the risk as much as simply connecting to uncontrolled networks.
The connection risk indicates increased education effort, and quarantine
procedures.  These steps provide momentum toward handling any compromise
along this vector.  I feel justified in listing this as a marginal
increase in risk.

   While my own experience is that few networks practice the above steps
in a comprehensive way, much progress has been made.  Today's networks
are much more resistant to this sort of vulnerability than just a year
ago.  Some networks have been compromised by using this exploit.  Fewer
still will notice.  That responsibility rests squarely on the management
and administrators of each network.  With that level of resources
applied, I find it hard to recommend an "unofficial" patch. 

   Your thoughts are appreciated.  Please include my address on the to
line for replies.  


Bill Scherr, IV  GSEC, GCIA
Jericho, VT

Key fingerprint = 4687 DEB0 E772 B94F 383E  8CB2 F2FC A46D A4A2 DC71
uid Bill Scherr IV <bschnzl at cotse.net>
KID 0xA4A2DC71

_________________________________________
Learn about Intrusion Detection in Depth from the comfort of your own
couch:
https://www.sans.org/athome/details.php?id=1341&d=1

_______________________________________________
send all posts to list at lists.dshield.org
To change your subscription options (or unsubscribe), see:
http://www.dshield.org/mailman/listinfo/list



More information about the list mailing list