[Dshield] WMF - SETABORTPROC alarms

Ed Truitt ed.truitt at etee2k.net
Mon Jan 2 19:26:23 GMT 2006

My analysis/response/commentary is included, in line with your email.

bschnzl at cotse.net wrote:

>   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.
Over 50 variants (separate exploits) within about a 48-hour period 
pretty much sets a record.  This one appears to affect EVERY VERSION OF 
WINDOWS, starting with Windows 3.0.  It was a design feature, for crying 
out loud!  I think this one will be far worse than any previous 
exploit/attack, once all is said and done.  We will probably be dealing 
with this for years to come, and in fact may never know exactly how many 
machines were compromised.  IMHO, this is a very serious issue, indeed, 
and one that we ignore at our peril.

>   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.
There are, however, some reports of automatic propogation ("worm" 
activity).  And, this thing is getting spammed through email and IM, and 
unfortunately people insist on clicking on those links, despite what we 
tell them not to do.

>   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.
However, some applications (such as Google Desktop) will open the file 
enough to trigger the vulnerability.  Consider it "semi-automatic" 
propogation, at least.

>   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.
True.  However, servers still get compromised, which means someone isn't 
paying attention to all that training that have been getting.  Plus, too 
many administrators are given it as an "additional duty", with minimal 
training involved.

>   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.
True.  HOWEVER, if the payload is yet another exploit which allows code 
execution in the SYSTEM context, the machine is 0wn3d.

>   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.
Most of us know this, but too many NetBIOS (Windows Networking) 
connections to the Internet still exist.

>   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.
More than marginal, IMHO.  Road Warriors bringing bad stuff in from the 
outside is probably how most of the recent attacks have gotten into my 
employer's network, right alongside the uncontrolled (and strictly 
against policy) Internet access points.

>   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.  
If we all practiced safe computing 100% of the time, I might agree with 
you.  However, seeing what Blaster, Zotob, Slammer, and their kind have 
done to networks that have been (or should have been) secure, I don't 
take any comfort at all in these facts.  In general, I agree that 
"unofficial" patches should be avoided if at all possible.  In fact, I 
am not going to recommend to my employer that we deploy this 
"unofficial" patch.  However, I do think (and will recommend) that we at 
least review it, so that we have something available in case things blow 
up in our faces.  Spend a lot of effort on it?  Probably not, but if 
Microsoft doesn't release an 'official' patch this coming January, and 
if the number of exploits continues to grow, I don't see that I can 
recommend simply sitting on our hands.  As far as unregistering the DLL 
that is vulnerable, I am going to recommend we have that available as an 
option, as Microsoft includes it as a workaround in their security 
advisory.  Again, YMMV.

>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

Ed Truitt
PGP fingerprint:  5368 D25E 468C A250 9833  CCD6 DBAE 9C25 02F9 0AB9

"Note to spammers:  my 'delete' key is connected to YOUR ISP.
 Also, if you send me UCE, I reserve the right to post your spew
on my Web site, with the appropriate color commentary, so that
others may have a good laugh at your expense."

More information about the list mailing list