Message-ID: <539740BD98FFB246BADB964D8D6792D3018211F070@EMASC205VS01.exchad.jpmchase.net>
Date: Wed, 8 Sep 2010 13:51:08 -0400
From: "Everhart, Glenn" <glenn.everhart@...se.com>
To: Christian Sciberras <uuf6429@...il.com>, YGN Ethical Hacker Group
	<lists@...g.net>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
	"bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: Re: KeePass version 2.12 <= Insecure DLL
 Hijacking Vulnerability (dwmapi.dll)

So you might then add another pass of making a hash after the details of
transaction are known that embodies transaction details, then use oblivious
transfer again so that each end knows that the transaction was done and
was thus accepted?

Takes care of someone taking over the transaction perhaps, and this could
bind in the initial data so the password exchange might be rechecked.

In the first step though, there is a reliance by the client that the server
uniquely knows the password, as it seems. If many servers know that password,
at best the client knows the server is one of those that know it.

If something at the client end fiddles with the transaction, the above kind of
signing only says that the client end is consistent, does not ensure the
user at that end actually has anything to do with those bits.

At any rate, for such a thing to work you want something better than the
usual "12345" kind of password, and to overcome things like the reported 73%
of the population who use the same password for everything.

This use of oblivious transfer though, giving mutual proof, is a useful 
primitive.

Glenn Everhart


-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Christian Sciberras
Sent: Wednesday, September 08, 2010 1:07 PM
To: YGN Ethical Hacker Group
Cc: full-disclosure@...ts.grok.org.uk; bugtraq@...urityfocus.com
Subject: Re: [Full-disclosure] KeePass version 2.12 <= Insecure DLL Hijacking Vulnerability (dwmapi.dll)

With the recent MS update/patch and my POC failure (to exploit the
vuln), it is clear that this type of "vulnerability" is impractical.
In the (few) cases where it *might* work, the approach to fixing it is
not practical; that is, there are hundreds if not thousands, of
vulnerable applications.
Just consider that DWM (as in above) is loaded via well known and
widely used API.
If that ain't proof enough, see what they did with mshtml in Notepad.
Whichever the case, it is not the application's fault, but the
underlying dll loading mechanism.
Having each vulnerable application's developer fixing it is hardly
practical, thus, your (and other related) reports are, mildly put, a
huge waste of time.

Cheers,
Chris.




On Wed, Sep 8, 2010 at 10:36 AM, YGN Ethical Hacker Group
<lists@...g.net> wrote:
> A vulnerability is a vulnerability.
> A SQL Injection is a type of Vulnerability.
> For each type of Vulnerability, there will be thousands of web
> applications that might be vulnerable to it.
> DLL Hijacking is same.
>
> We do each post rather than a list so that security vulnerability news
> site can get required detailed information
> as possible.
>
> If you don't want it, set filter for each post subject with "DLL
> Hijacking" or from our email.
>
> We can't underestimate such an easy flaw that leads to system
> compromise or command execution under user' privilege.
>
> Disabling remote share/WebDav is not a solution to DLL Hijacking at all.
>
> DLL Hijacking is highly effective in combination with the use of
> Social Engineering Toolkit.
>
>
>
>
> On Tue, Sep 7, 2010 at 2:28 PM, Christian Sciberras <uuf6429@...il.com> wrote:
>> I'm getting a bit tired of throwing away these "security advisories".
>>
>> Really, someone should install a whole load of popular applications, ensure
>> any of them load their own files, and finally, thanks to a mass dependency
>> check, ensure DWM is being loaded at runtime.
>>
>> At least, it would be just one email/thread to trash.
>>
>>
>>
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
 If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.

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

Powered by blists - more mailing lists