Re: Compromising pictures of Microsoft Internet Explorer!

[Dave Aitel <dave () immunitysec com>]

They're going to use a different system - one that's not as vulnerable,
or has secondary methods of protection. Say, Linux, or a HIDS of some
sort. Any HIDS worth it's base price will protect against this sort of
thing. Or they'll invest in buying machines that support the NX bit and
install SP2. Not knowing about the bugs does not make you more secure.
Believe me, finding bugs is not the hardest thing in the world.

What Michal Zalewski did was tell people they were vulnerable, and how
vulnerable they were. They, including your clueless self, are now free
to make real descisions about their level of security. For this free
work, you, and the mindless drones like you, are giving him undeserved
shit because you bought some corporation's public relations line, to the
point of parroting their terminology. Those of us who actually are in
the hacking community think it is your small mind that is the
irresponsible disgrace.

-dave

tuytumadre () att net wrote:

> I do not meen to flame you, but you are an irresponsible disgrace to
> the hacking community. Do you not care about the customer? You never
> publicly disclose details to a vulnerability of this magnitude. This
> is an image vulnerability, for crying out loud. What's the first thing
> they tell you to do when most vulnerability details are released?
> Disable active scripting. That doesn't work here. What are the
> innocent, ignorant computer users going to do? Disable images? I think
> not. You should be ashamed.
>
>  
>
> I firmly believe that you are decieving us when you say you had a hard
> time with secure () microsoft com <mailto:secure () microsoft com>; in fact,
> I don't even think that you have ever once in your life reported a
> vulnerability to them responsibly. Otherwise, you would not have such
> harsh feelings about them. If the evil of the stereotypical Microsoft
> machine exists anywhere on the campus in Redmond, it will not be found
> in the building of MSRC, which is where your secure () microsoft com
> <mailto:secure () microsoft com> emails are directed.
>
>  
>
> Come on man. I know you have talent. You are a good researcher of
> computer security. But if your talent is going to be wasted like this,
> you are nothing more to us than a script kiddie.
>
>  
>
> Regards,
>
> Paul
>
> Greyhats Security
>
> http://greyhatsecurity.org
>
>  
>
>     -------------- Original message from Michal Zalewski
>     <lcamtuf () dione ids pl>: --------------
>
>
>     > Synopsis:
>     > ---------
>     >
>     > Well, not really. Instead, at the risk of boring you to death,
>     I'd like
>     > to report on a casual 30-minute experiment I've conducted of
>     recent.
>     > This experiment resulted in identifying a potential remote code
>     > execution path in Microsoft Internet Explorer, plus some other
>     bugs, and
>     > should be a good starting point for further testing of other
>     browsers or
>     > similar programs.
>     >
>     > Discussion:
>     > -----------
>     >
>     > You might remember the 'mangleme' affair, where various browsers
>     were
>     > subjected by yours truly to a trivially constructed malformed HTML
>     > crash-course - all that in order to find exploitable input
>     handling flaws.
>     > Back then, MSIE pe rformed admirably compared to other browsers
>     (although
>     > did not escape some embarassment when ned@felinemenace found the
>     > infamous IFRAME bug that way):
>     >
>     > http://lcamtuf.coredump.cx/mangleme/gallery/
>     >
>     > Of recent, I decided to try something completely different and
>     radically
>     > new, without having to do any actual work. I used the same META
>     REFRESH
>     > auto-test framework to check for image decompression and parsing
>     flaws
>     > (JPEG, GIF, PNG), as opposed to making fun of HTML renderers.
>     >
>     > I used a simple index.cgi script (attached, though hardly
>     noteworthy) to
>     > dynamically generate a page that references ten just as dynamically
>     > created images. These images were prepared by running a test set of
>     > pictures (some regular ones, and several pathological cases
>     created with
>     > ImageMagick) through a slightly modified version of my old afx
>     utility.
>     >
>     > Surprisi ngly, it is MSIE and its proprietary JPEG decoder
>     (apparently
>     > not shared with other Windows components?) that performed
>     embarassingly
>     > poor this time. Results below.
>     >
>     > Vulnerability examples:
>     > -----------------------
>     >
>     > NOTE #1: As with mangleme, this list of problems is most
>     certainly NOT
>     > exhaustive, and performing longer tests or improving the technique
>     > would most likely result in additional findings.
>     >
>     > Several MSIE crash sample files from that 30-minute run are
>     available
>     > at:
>     >
>     > http://lcamtuf.coredump.cx/crash/
>     >
>     > Note that these may produce different results depending on program
>     > versions, plugins and configuration. Tested with WinXP Pro PL
>     > 2600.xpsp2.050301-1526 SP1, MSIE PL 6.0.2800.1106, up-to-date.
>     >
>     > mov_fencepost.jpg - on most platforms, causes a crash due to mov
>     > destination fencepost error after g oing past allocated memory, or
>     > after accessing a bogus address such as 0x27272727. The destination
>     > address appears to be controllable (i.e. changing the file or
>     > displaying other data before or along with this image alters it).
>     > My bets are that this is exploitable for remote execution.
>     >
>     > cmp_fencepost.jpg - here, causes a crash due to a very similar cmp
>     > fencepost (no write). Not necessarily exploitable for remote code
>     > execution, unless code execution path can be affected later on.
>     >
>     > oom_dos.jpg - usually causes a OOM crash. Less interesting, unless
>     > you like to punish people who borrow your pictures for their blogs.
>     >
>     > random.jpg - causes mov fencepost of CPU consumption + crash.
>     Didn't
>     > investigate in much detail.
>     >
>     > NOTE #2: MSIE comes with no sources, and reverse engineering is
>     naughty.
>     > I didn't examine the renderer to see what went w rong; I see
>     unbounded,
>     > user-dependent memory accesses, and that spells trouble.
>     >
>     > Vendor notification:
>     > --------------------
>     >
>     > It is my experience that reporting and discussing security
>     problems with
>     > Microsoft is a needlessly lengthy process that puts too much
>     burden and
>     > effort on the researcher's end, especially if you just have a crash
>     > case, not a working exploit; hence, they did not get an advance
>     notice.
>     >
>     > Bonus (OT)
>     > ----------
>     >
>     > Since piggyback request smuggling and fooling proxies and
>     filters is a
>     > popular new pastime, some of you might find it entertaining to
>     have a
>     > look at how various applications differ in handling duplicate
>     instances
>     > of HTTP/SMTP message/NNTP headers that are, in common perception,
>     > "supposed to" occur only once.
>     >
>     > --
>     > ------------------------- bash$ :(){ :|:&};: --
>     &g t; Michal Zalewski * [http://lcamtuf.coredump.cx]
>     > Did you know that clones never use mirrors?
>     > --------------------------- 2005-07-14 00:29 --
>     > http://lcamtuf.coredump.cx/silence/ 
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/