Full Disclosure mailing list archives

Previous By Date Next
Previous By Thread Next

Re: KeePass version 2.12 <= Insecure DLL Hijacking Vulnerability (dwmapi.dll)

From: "Everhart, Glenn" <glenn.everhart () chase com>
Date: Wed, 8 Sep 2010 13:51:08 -0400
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 () lists grok org uk [mailto:full-disclosure-bounces () lists grok org uk] On Behalf Of 
Christian Sciberras
Sent: Wednesday, September 08, 2010 1:07 PM
To: YGN Ethical Hacker Group
Cc: full-disclosure () lists grok org uk; bugtraq () securityfocus 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 () yehg 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 () gmail 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/
Previous By Date Next
Previous By Thread Next

Current thread: