full-disclosure - Re: [ GLSA 200601-09 ] Wine:Windows MetafileSETABORTPROC vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ace868f90601131434x2a3165f9ne70c4cdb1180fcad@mail.gmail.com>
Date: Fri Jan 13 22:34:42 2006
From: nfobro at gmail.com (eric williams)
Subject: Re: [ GLSA 200601-09 ] Wine:Windows
	MetafileSETABORTPROC vulnerability

On 1/13/06, Peter Ferrie <pferrie@...antec.com> wrote:
> Todd Towles:
>
> >>Can anyone else verify Steve Gibson's assertion that this
> >>flaw was intentionally placed by Microsoft programmers?
>
> It's insecure-by-design, but it's working exactly as written.
> It's been in there for _15_ years, and ported to every version of Windows.
> Windows 3.0 supports it. :-/
>
> bkfsec:
>
> >The way I read what he's saying there, he's saying that you enter
> >malformed input and that malformed input pushes the executable code into
> >position to be executed...
>
> There is no need for malformed input, though.
> The description isn't great, since upon return from the function, Windows
> will resume parsing the records in the usual way.

IDK, but from reading the transcript there is malformed input in the
form of an invalid record length that Gibson refers to, did you test
the older metafile processing routines of the GDI, Peter?  It would be
interesting to know whether the execution of a new thread is triggered
by the same circumstances in all versions of Windows.

I also don't know about the assertion of older versions of the GDI
being vulnerable, but I *do* expect there may be merit in pursuing
that.  I think Gibson, if what he says is true makes an interesting
argument concerning  the invalid length == 1 issue.  AFAICT, what he
infers is that no "coding error" would result in only that value
sparking off a new thread based on a content provider supplied code
execution vector.  It is probably worth testing other values, of
course one might expect to see other flaws expressed if they exist by
doing that.

Still, it is hard for me to concieve of this as being anything more
than a design flaw that as someone said before resulted from 'ease of
use / feature creep' -- perhaps it was even a requested feature by
some third-party vendor, who knows?

-e

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