'crossfuzz'에 해당되는 글 1건

  1. 2011.01.04 cross-fuzz라는 브라우저 관련된 0day 취약점 발표

심각한 파급력을 가질 수 있는 보안 취약점을 발견 즉시 공개해야 할까요? 아니면, 개발사와 충분히 검토하여 문제점을 해결 또는 완화할 수 있는 방안(패치)를 마련한 다음 공개해야 할까요?

보통, 후자의 경우를 선택하는 경우가 많으며, 요즘은 인식이 많이 좋아져서 개발사에서도 적극적으로 대처하는 편입니다.

하지만, 작년 9월과 올 1월에 구글에서 근무하는 엔지니어가 새로운 제로데이 취약점을 공개해서 논란이 되고 있습니다. 앞에서 언급한 바와 같이 문제점의 해결책이 마련되지 않은 상태에서 공격이 가능한 코드(PoC, Proof of Concept)를 공개한 것이 논란의 발단입니다.

Lcamtuf와 Michael Zalewski는 자신들이 발견한 cross-fuzz라는 취약점을 이용하는 공격이 가능함을 시연하는 툴을 최근 공개했습니다.

1. Open two windows with documents of any (DOM-enabled) type. Simple HTML, XHTML, and SVG documents are randomly selected as targets by default - although any other, possibly plugin-supported formats could be targeted instead.
2. Crawl DOM hierarchy of the first document, collecting encountered object references for later reuse. Visited objects and collected references are tagged using an injected property to avoid infinite recursion; a secondary blacklist is used to prevent navigating away or descending into the master window. Critically, random shuffling and recursion fanout control are used to ensure good coverage.
3. Repeat DOM crawl, randomly tweaking encountered object properties by setting them to a one of the previously recorded references (or, with some probability, to one of a handful of hardcoded "interesting" values).
4. Repeat DOM crawl, randomly calling encountered object methods. Call parameters are synthesized using collected references and "interesting" values, as noted above. If a method returns an object, its output is subsequently crawled and tweaked in a similar manner.
5. Randomly destroy first document using one of the several possible methods, toggle garbage collection.
6. Perform the same set of crawl & tweak operations for the second document, but use references collected from the first document for overwriting properties and calling methods in the second one.
7. Randomly destroy document windows, carry over a percentage of collected references to the next fuzzing cycle.


이 취약점은 2010년 7월부터 제기된 것으로 그동안 인터넷 익스플로러, 파이어폭스 등과 같은 브라우저에서 발생하는 문제를 해결해 오고 있는 상태였으며, 이에 대한 정보는 아래를 참고하십시오.

Internet Explorer: MSRC notified in July 2010. Fuzzer known to trigger several clearly exploitable crashes (example stack trace) and security-relevant GUI corruption issues (XP-only, example). Reproducible, exploitable faults still present in current versions of the browser. I have reasons to believe that one of these vulnerabilities is known to third parties.

Comment: Vendor has acknowledged receiving the report in July (case 10205jr), but has not contacted me again until my final ping in December. Following that contact attempt, they were able to quickly reproduce multiple exploitable crashes, and asked for the release of this tool to be postponed indefinitely. Since they have not provided a compelling explanation as to why these issues could not have been investigated earlier, I refused; see this timeline for more.
All WebKit browsers: WebKit project notified in July 2010. About two dozen crashes identified and addressed in bug 42959 and related efforts by several volunteers. Relevant patches generally released with attribution in security bulletins. Some extremely hard-to-debug memory corruption problems still occurring on trunk.
Firefox: Mozilla notified in July 2010. Around 10 crashes addressed in bug 581539, with attribution in security bulletins where appropriate. Fuzzing approach subsequently rolled into Jesse Ruderman's fuzzing infrastructure under bug 594645 in September; from that point on, 50 additional bugs identified (generally with no specific attribution at patch time). Several elusive crashes still occurring on trunk. Bad read / write offset crashes in npswf32.dll can also be observed if the plugin is installed.
Opera: vendor notified in July 2010. Update provided in December states that Opera 11 fixed all the frequent crashes, and that a proper security advisory will be released at a later date (release notes list a placeholder statement: "fixed a high severity issue"). Several tricky crashes reportedly still waiting to be resolved.

재미있는 점은 마이크로소프트가 이 취약점을 해결하는 패치가 발표되기 전까지는 공격 코드의 발표를 연기해 달라고 요청했다는 점인데, 이 요청을 거부하고 공개했다는 것입니다. 

Michael Zalewski는 이러한 요청을 거부한 배경에는 이미 이 취약점을 이용하는 공격도구가 이미 인터넷 상에 존재하고 있다고 믿을 만한 근거가 있다고 밝혔습니다.


즉, 이미 인터넷 상에 취약점이 공개되어 공격자들이 이용하고 있는데, 해결책이 없다고 주저하는 것이 옳은 선택일까요? 아닐까요?

출처: http://lcamtuf.blogspot.com/2011/01/announcing-crossfuzz-potential-0-day-in.html

 

reTweet
Posted by 문스랩닷컴
blog comments powered by Disqus


    Web Analytics Blogs Directory