Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Where you should disclose your vulnerabilities. Go read RFPolicy if you want to do responsible disclosure, and go here for when all else fails. 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
URI Handling Vulnerabilities
Posted by: BK
Date: July 25, 2007 04:55AM

Interesting post from ma1:

“You may want to add that the relevant Mozilla bug has been fixed 2 days ago.
This means that already available Minefield builds and Firefox 2.0.0.6 release candidates are immune. Furthermore, NoScript 1.1.6.06 (released yesterday) gives early protection against this exploit for those stuck with stable 2.0.0.5.”

Ma1… once again.. you have bridged the gap between 0-day and vendor patch… and we are grateful… I just wish IE had a plug-in similar to NoScript!

Nate and I (BK) fully understood that this particular vulnerability would be addressed by Firefox 2.0.0.6… in fact the only reason we disclosed this vulnerability now (as opposed to two months ago, when we first discovered this issue) was because we knew Firefox (Mozilla) would be addressing it soon….The latest patch from Mozilla may fix this particular vulnerability… but it doesn’t fix URI handling vulnerabilities in general…

Myself, Nate, and Raghav (“the Pope”) understood that ALL browsers would one day sanitize all “illegal” input from URIs… BUT IT STILL DOESN’T solve URI handling vulnerabilities… browser filtering is only PART of the bigger issue…. it is still possible to pass “legal” arguments to MANY, MANY applications on behalf of the user. Think of this as the ultimate Cross Site Request Forgery (Cross Application Request Forgery). Even if the browser sanitized ALL “illegal” characters it is STILL POSSIBLE to use registered URIs to execute functionality on behalf of the user…. Just look at the aim.dll overflow disclosed by Nate and I and try to find an illegal character in that attack vector. http://www.xs-sniper.com/nmcfeters/Cross-App-Scripting-2.html

I’m ecstatic to see that browsers are taking measures to protect users… but browsers are ONLY half of the equation…. it’s time that developers understood that registering a URI handler increases the attack surface for their application EXPONENTIALLY. Now, anytime their user falls victim to XSS or CSRF, ANY security flaw in their application logic now becomes remotely exploitable.

This is NOT just an IE issue… it's NOT just a Firefox issue… it an issue that lies within every application that registers a URI handler… do YOU know what URI handlers are registered on your machine http://erik.cabetas.com/?p=stuff ?

BK
-----
XS-Sniper.com



Edited 1 time(s). Last edit at 07/25/2007 05:39AM by BK.

Options: ReplyQuote
Re: URI Handling Vulnerabilities
Posted by: BK
Date: July 25, 2007 05:38AM

A nice list of URL handlers has been provided by mozilla.... its missing a couple that Nate, Ragahv, and I have looked at... but its still pretty good..

https://bugzilla.mozilla.org/attachment.cgi?id=273560&action=edit

BK
------
XS-Sniper.com

Options: ReplyQuote
Re: URI Handling Vulnerabilities
Posted by: Anonymous User
Date: July 25, 2007 05:45AM

Nice list!

Do you also have a way to enumerate through registered resource identifiers remotely yet?

Options: ReplyQuote
Re: URI Handling Vulnerabilities
Posted by: BK
Date: July 25, 2007 06:15AM

The RES local software enumeration works well with URI handler identification http://ha.ckers.org/blog/20070721/res-protocol-local-file-enumeration/... you check to see if a particular software is installed on the machine, then if that software typically registers a URI, then the chances are good that the particular URI is registered....

BK
----
XS-Sniper.com

Options: ReplyQuote
Re: URI Handling Vulnerabilities
Posted by: hackathology
Date: July 25, 2007 11:13PM

A pretty decent list...

http://hackathology.blogspot.com

Options: ReplyQuote


Sorry, only registered users may post in this forum.