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-boun...@lists.grok.org.uk [mailto:full-disclosure-boun...@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; bugt...@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 <li...@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 <uuf6...@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/
