[Dshield] WMF - SETABORTPROC alarms

John B. Holmblad jholmblad at aol.com
Tue Jan 3 16:54:51 GMT 2006


Brian,

thanks for the clarification. I have to say, at the same time, that  the 
conventional usage of the term "execute arbitrary code" is not uniform. 
I don't have specific examples to cite here but I have seen instances 
where the phrase "......in the security context of the logged in 
user..." or something similar has been added to the description. If your 
interpretation of the term "execute arbitrary code" is correct, then 
such conditional statements would not be necessary.  Given this 
ambiguity, whenever I see the term used without qualification I try to 
look for additional sources to see if those additional sources add the 
qualification of the scope. I think it would be helpful if the authors 
of such alerts would always explicitly indicate the scope of privilege 
escalation that is possible with the exploit whose effects they are 
describing.

Best Regards,

John Holmblad

Televerage International
GSEC Gold,GCWN Gold,GGSC-0100,NSA-IAM,NSA-IEM

(H) 703 620 0672
(M) 703 407 2278
(F) 703 620 5388

primary email address:     jholmblad at aol.com
backup email address:      jholmblad at verizon.net



Brian Dessent wrote:

>bschnzl at cotse.net wrote:
>
>  
>
>> Arbitrary boils down to root (or SYSTEM in this case, as if I need to tell this list).
>>    
>>
>
>Uh, what?  No.  "Arbitrary code" means that the attacker has full
>control over the nature of the code that's run.  It says nothing about
>whether privileges can be escalated, which may or may not be the case. 
>It's a completely separate variable, and often exploits are chained to
>combine a buffer overflow (arbitrary code excution) with a local
>privilege escalation.
>
>Anyway, in this case the WMF vuln has no such privilege escalation
>element whatsoever.  All you get is the current security context of the
>current user, no more, no less.  Of course, it's very much the case that
>the local user is often the administrator, so on windows this
>distinction is not really always relevant but it still exists.
>
>And by the way, Administrator access is very different than SYSTEM, they
>are not the same in any stretch.  The former is a regular user account
>and still has restrictions on what it can do -- for example, you cannot
>kill processess of services, even as an administrator.  But the
>administrator does have the necessary privileges to install new services
>or drivers, and this can be leveraged to actually perform those tasks. 
>This is why you can't kill services using TaskMgr but you can using
>Process Explorer -- the latter includes a driver as a resource inside
>the .exe which is actually installed in realtime when you run the
>program to act as a proxy for the actions whih can only be performed as
>the SYSTEM user and not a regular user/administrator.  You will find in
>fact that most of the sysinterals tools do this (clandestinely install
>drivers) because a number of the things that it does require kernel mode
>or SYSTEM-user privilege.
>
>Brian
>_________________________________________
>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