(as apllied to Full Trust Asp.Net vulnerabilities) Re: [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!

[Dinis Cruz]

I also had similar experiences with dealing with MSRC (Microsoft
Security Response Center) where they were quite pedantic and wanted me
to send them very detailed information about the issues that I was
talking about

Eventually I realized that it was not that they were not understanding
what I was saying, it was that they wanted to know how much I (me,
Dinis) understood about the issue and how to exploit the
vulnerabilities.

And in my case it was worse, because we were arguing about the
'definition of a vulnerability' where I was telling them that a
malicious Full Trust Asp.Net script could take over an entire server
(even following Microsoft's recommended security best-practices) and
they where saying that THAT is not a vulnerability since what I was
exploiting was 'built-in' functionality in the .Net framework to attack
the server.

Their answer to all issues I mentioned (for example: all
usernames/passwords stored in the metabase can be decrypted by any
member belonging to the IIS_WPG, the reuse/hijack of the Security
Tokens that exist in a  IIS Process, the upload and execution of
binaries/exploits to the server, the fact that most published
security-advisories also apply to Full Trust Asp.Net/IIS environments,
the asp.net temporary folders, the default access to WMI, the fact the
IIS 6.0 doesn't scale very well when multiple Applications pools are
used,  etc...) is: "that occurs by design in Full Trust Asp.Net" 

Eventually I gave up, and since most of the people who should care (for
example ISPs, software developers, end-clients) don't care (or are not
aware), I decided that the best use of my time and effort would be to
write tools that help responsible and security-conscious administrators
to identify vulnerabilities in their hosting environments. This is what
I did at Owasp (Open Web Application Security Project) where you will
find several tools that I wrote: ANSA (Asp.Net Security Analyzer),
SAM'SHE (Security Analyzer for Microsoft's Shared Hosting Environments)
, Asp.Net Reflector, Online Metabase Explorer, etc... (The main Owasp
website is at www.owasp.org and the dotnet section is at www.owasp.net.)

Note that I have been warning Microsoft about these issues for more
that 18months now, and finally it seems to exist some interest in
acknowledging them (I had a meeting last week in Redmond where we
discussed this) and at least now (July 2005) they seem to want to do
something about it (the first step will be to acknowledge the problem).

Although I believe that some care must be placed in the disclosure of
0-day style vulnerabilities that can be maliciously exploited by worms
and virus, I don't believe that we should subscribe to the COTS
'responsible vulnerability disclosure' ideas since they are designed to
minimize the impact of the vulnerabilities in their stock price,
instead of increasing the security of their products and clients.

In fact, I have to say that Microsoft for all its sins, it is not the
worse one in this aspect. At least Microsoft will do the right thing
when shown a vulnerability which can be maliciously exploited in a
massive scale. I have had several past experiences where I was working
for Client X, testing Product Y, and after delivering my report
(containing several critical vulnerabilities on Product Y) only Client
X received a patch (because the other clients that used this product
were not aware of these vulnerabilities, they never complained, where
never told about this issues and only received the patch in the next
'service pack').

And as the low-hanging fruit vulnerabilities dry up, and more time is
required to find existing vulnerabilities, it is very important that we
have clear, honest and object discussions about vulnerability
disclosure.

But, since this discussion is not possible today (there is too much
'emotion in the air' :) ), and Full (or almost Full) disclosure of
vulnerabilities is not always possible (for example when
vulnerabilities are discovered under NDAs) I think that the best
solution is for companies to be forced (maybe by government legislation
or by client pressure)  to disclose how many vulnerabilities in their
products/websites their are aware of (either found internally 
communicated to them by a client or security research company). This
could be a bit like what eEye does these days when they say that a
vulnerability has been discovered, when it was discovered/communicated
to the vendor, talk about the it impact, but don't publish technical
details about it until a patch is released.

Dinis Cruz
.Net Security Consultant
Owasp .Net Project Leader


Bernhard Mueller wrote:

  
Mr. Zalewski's statement about the undue burden that Microsoft's
investigative processes place on the researcher is indeed accurate.  The
only time I've had any success working with Microsoft was when the issue
was a straightforward code execution scenario.  Oh wait... even then,
I'm blown off.

  
  
the same here... when I mailed them about that CO

Re: [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!

[Tom Ferris]

Bernhard Mueller wrote:


Mr. Zalewski's statement about the undue burden that Microsoft's
investigative processes place on the researcher is indeed accurate.  The
only time I've had any success working with Microsoft was when the issue
was a straightforward code execution scenario.  Oh wait... even then,
I'm blown off.
   



the same here... when I mailed them about that COM-vulnerability in IE,
they came up with "this is not exploitable, bla.." after two weeks of
internal research
and all. having a bad morning anyway, I decided to post the advisory and
see, one day later there's a MS security advisory that "a COM object may
crash internet explorer" (however, they forgot to mention the public
bindshell exploit released by the fsirt).
now recently MS05-37 came out, which somehow doesn't include any credits
 or mention of the original advisory whatsoever (the reason for that
being, i presume, the lack of responsibility showed by us).
I think it's rather strange to hear a billion-dollar software monopolist
apply to my conscience like "look what you've done, you put our
customers at risk". they wouldn't give a lame cent on the security of
their customers if there wasn't a certain media hype about security.
they care for their image and stock index, and that's about it. and i
don't see why should be held responsible for that ;)


regards,

sk0L
 

I think it all boils down to how black of an eye they want to give 
themselves.  If and when its a clean code execution, they have to say it 
is because you and I all know that when the exploit is published it 
makes then look even worse.  In a way, I am kind of dealing with this 
same scenario.


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

Re: [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!

[Bernhard Mueller]

> Mr. Zalewski's statement about the undue burden that Microsoft's
> investigative processes place on the researcher is indeed accurate.  The
> only time I've had any success working with Microsoft was when the issue
> was a straightforward code execution scenario.  Oh wait... even then,
> I'm blown off.

the same here... when I mailed them about that COM-vulnerability in IE,
they came up with "this is not exploitable, bla.." after two weeks of
internal research
and all. having a bad morning anyway, I decided to post the advisory and
see, one day later there's a MS security advisory that "a COM object may
crash internet explorer" (however, they forgot to mention the public
bindshell exploit released by the fsirt).
now recently MS05-37 came out, which somehow doesn't include any credits
  or mention of the original advisory whatsoever (the reason for that
being, i presume, the lack of responsibility showed by us).
I think it's rather strange to hear a billion-dollar software monopolist
apply to my conscience like "look what you've done, you put our
customers at risk". they wouldn't give a lame cent on the security of
their customers if there wasn't a certain media hype about security.
they care for their image and stock index, and that's about it. and i
don't see why should be held responsible for that ;)


regards,

sk0L
-- 
_

~  DI (FH) Bernhard Mueller
~  IT Security Consultant

~  SEC-Consult Unternehmensberatung GmbH
~  www.sec-consult.com

~  A-1080 Wien  Blindengasse 3
~  Tel:   +43/676/840301718
~  Fax:   +43/(0)1/4090307-590
__

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

Re: [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!

[Michal Zalewski]

On Sat, 16 Jul 2005, [EMAIL PROTECTED] wrote:

> I do not mean to flame you, but you are an irresponsible disgrace to the
> hacking community.

You do mean to flame me, apparently, and constructing sentences this way
makes them unintentionally funny. Pretty much like saying "Sir, with all
due respect, you are a filthy low-life scum".

> Do you not care about the customer?

I do security research for fun. Because I mean no harm, I usually take
efforts to notify vendors in advance, or release advisories that are of
more value to those who want to fix problems, than to those exploiting
them. The latter is the case here. The former isn't, because I had a poor
experience with the vendor.

That about sums up my philosophy. No, I do not particularly care about
Microsoft customers - Microsoft should.

> I firmly believe that you are decieving us when you say you had a hard
> time with [EMAIL PROTECTED]; in fact, I don't even think that you
> have ever once in your life reported a vulnerability to them
> responsibly.

I did, a couple of times. In fact, if you had gone through the effort of
actually using a search engine, you would find out that I did coordinate
some stuff with them.

It is my experience, however, that they require you to:

  1) Prove them beyond any doubt that a particular issue is exploitable;
 they seem to be doing this not to fully comprehend the threat, but
 to see if you are not absolutely certain on all the phases of the
 attack, and then exploit the benefit of doubt. You need to either:

 a) Debug their code in great detail and explain the execution path
 that leads to this, along with an explanation why overwriting an
 arbitrary byte in memory might cause problems,

 b) Provide an exploit that works for them (and be sure it also
 works on SP2, or they will come up with ridiculous recommendations
 - look up the Bofra IFRAME stuff),

 c) Find a bug that is so patently obvious it hurts (stack buffer
 overflow, for example).

 If you fail to do that, they - in my opinion - use this to downplay
 the issue. Look up how many times Microsoft considered something to
 be less critical than the researcher would believe it to be - and
 were proved wrong by having exploits developed later on. How
 often does the opposite happen?

  2) Wait forever for them to release a patch. Frankly, I see no reason
 why a multi-billion dollar company with so many customers at risk
 would need to take more than a week or two to develop, test and
 release trivial fixes.

  3) Most insidious - if you happen to work for a company that depends on
 Microsoft in one way or another (for example, to recommend, bundle,
 or just not break your products), when you disagree with them, I
 seem to recall they would take an opportunity to give you a friendly
 reminder it would be "unwise" not to agree in your advisory.

All this, combined with the general disregard for the customer who does
not immediately vote with his money (lacking viable options makes this
hard; if you're looking for real-world examples, how long it took
Microsoft to release goddamn patches after Bofra went loose?!), makes me
somewhat less interested in investing several weeks into this type of
cooperation.

/mz
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/

Re: *****SPAM***** Re: [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!

[Georgi Guninski]

oh, no. long time no m$ puppies whining publicly.

On Sat, Jul 16, 2005 at 07:43:32PM +, [EMAIL PROTECTED] 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 do not mean to flame you, but please stop smoking illegal stuff.

why should lcamtuf care about m$ customers - m$ customers have deal with m$.
it is a problem of m$, not of lcamtuf. does m$ care about free software
customers?

just check the m$ eula on the topic of "responsibility" and see the official
party line of taking responsibility.

what can m$ lusers do?:

- call toll free support and ask what the fuck is going on, asking for a
ticket number.
- switch to a real os.

about [EMAIL PROTECTED] - at least technically they are dumb and ignorant from 
personal experience. they don't care about bugs, bugs are a burden for them. 
they care about $$$.

these same lamers continue to whine even if one reports a bug to them, but
doesn't wait long enough for them to scratch their testicles.

-- 
where do you want bill gates to go?











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

Re: [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!

[Dave Aitel]

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

[EMAIL PROTECTED] 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 [EMAIL PROTECTED] ; 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 [EMAIL PROTECTED]
>  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
> <[EMAIL PROTECTED]>: --
>
>
> > 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 [EMAIL PROTECTED] 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
> > v

Re: [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!

[Matthew Murphy]

[EMAIL PROTECTED] 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.


Sure you do.  You disclose the details of the vulnerability when the 
vendor has a proven history of non-responsiveness, and the damage that 
the vendor is able to do by stalling the release is most likely greater 
than the damage that will result from disclosure of several non-critical 
flaws.  AFAICT, IE 6.0 SV1 merely crashes when faced with these issues.  
According to Microsoft, it's not a vulnerability at all unless there's 
an attack vector enabling code execution.


Mr. Zalewski's statement about the undue burden that Microsoft's 
investigative processes place on the researcher is indeed accurate.  The 
only time I've had any success working with Microsoft was when the issue 
was a straightforward code execution scenario.  Oh wait... even then, 
I'm blown off.


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.


The point you miss, is that thanks to Mr. Zalewski's decision to publish 
the details of this vulnerability ensures that AV/IDS signatures exist 
for the portion of users who care to update them.  Meanwhile, I can 
afford to wait the six, twelve, eighteen, or twenty four months that 
Redmond takes to patch IE issues.  Or, maybe it will be a refreshingly 
reduced timeline, only a month or two, since this is a supposedly 
critical issue.


 
I firmly believe that you are decieving us when you say you had a hard 
time with [EMAIL PROTECTED] ; 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 [EMAIL PROTECTED] 
 emails are directed.


...and I firmly believe that you have never had the experience of 
attempting to triage a vulnerability that was anything less than 
critical through Microsoft.  If you have, as I have, you'll understand, 
as I do, that it's possibly the closest thing to hell you'll go through 
in your research work.  The "evil of the stereotypical Microsoft 
machine" isn't as much an evil as an ineptitude.  Microsoft's current 
processes have huge problems with efficiency, quality, and effectiveness 
that have few parallels in the industry, and it isn't for lack of 
resources.  And aside from that, they require the researcher to provide 
a full, complete assessment of impact.  That's not feasible for a great 
number of us, who are, after all, nothing more than volunteers.


I'm a college student with a laptop and a few reverse engineering 
tools.  If an issue is discovered that appears to permit some degree of 
compromise of a customer's PC, I _should_ be able to count on the MSRC 
to investigate the issue sufficiently to prove that damage is 
sufficiently unlikely/impossible.  Instead, the inverse is true, with 
MSRC counting on me (the volunteer) to do the hours of research to prove 
that a vulnerability exists.  And if the impact is anything less than 
remote code execution, prepare for at best a lengthy debate, at worst 
your report being swept under the rug with a maintenance release that 
never actually happens.


The response (in a few less words) that many researchers have to these 
conditions is "F--- it!".  And, in my experience, it's certainly 
justified.  Why am I volunteering my time to one of the world's largest 
corporations, when they don't care enough about their customers to give 
fairly obvious security issues their due diligence?  After all, I don't 
have their code.


Particularly given Redmond's tendency to take eternities to solve bugs 
that are "responsibly disclosed" to it, I'm thankful that the action was 
taken as it was, and not as you wish, for my "safety and protection".  
If nothing else, Michal's report is further confirmation that Internet 
Explorer is one of the modern world's greatest programming disasters, 
and should be avoided at all costs, if you are a sysadmin intent on 
keeping your systems safe.


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.


Sorry, but you have about as much claim to speak for "us" as this e-mail 
speaks for you.  Now, at least my AV/IPS systems can attempt to block 
this attack.  Sure beats sitting waiting, uninformed, while Redmond 
deliberates over its delivery 

Re: [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!

[tuytumadre]

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 [EMAIL PROTECTED]; 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 [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>: -- > 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 [EMAIL PROTECTED] 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 

Re: [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!

[Przemyslaw Frasunek]

Michal Zalewski napisał(a):
>   random.jpg - causes mov fencepost of CPU consumption + crash. Didn't
> investigate in much detail.

This one works perfectly also on Opera 8.01.

-- 
* Fido: 2:480/124 ** WWW: http://www.frasunek.com/ ** NICHDL: PMF9-RIPE *
* JID: [EMAIL PROTECTED] ** PGP ID: 2578FCAD ** HAM-RADIO: SQ8JIV *
___
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] Compromising pictures of Microsoft Internet Explorer!

[Michal Zalewski]

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 performed admirably compared to other browsers (although
  did not escape some embarassment when [EMAIL PROTECTED] 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.

  Surprisingly, 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 going 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 wrong; 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$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
Did you know that clones never use mirrors?
--- 2005-07-14 00:29 --

  http://lcamtuf.coredump.cx/silence/#!/bin/bash

echo "Content-Type: text/html"
echo

ID="timg-$$-$RANDOM-$RANDOM"

rm -f timg-* AFX.log

cat <<_EOF_





_EOF_

CNT=0

for i in img/*; do
  CNT="$[CNT+1]"
  FNAM="$ID-$CNT"
  EXT=`echo $i | cut -d. -f2`
  ./afx-loc -p 1 -i 100 -m RANDOM -s 6 <$i 2>$FNAM.$EXT >>AFX.log
  echo "Test $CNT - "
done

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