Re: [Full-disclosure] Two MSIE 6.0/7.0 NULL pointer crashes
On Fri, 22 Jan 2010 04:42:56 EST, Jeffrey Walton said: > > Very few people use Microsoft software because of its security reputation. > Presuming 'people' equates to Desktop installations, the numbers I > have seen indicate otherwise. I think you misparsed what he said. You read it as "Because of its security reputation, very few people use Microsoft software". What he actually meant was "Very few people choose Microsoft with their security reputation as one of the primary considerations". pgpgZat2VFRsv.pgp Description: PGP signature ___ 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] Two MSIE 6.0/7.0 NULL pointer crashes
I agree, there's a world of a difference between Python and Perl. [joking] On Fri, Jan 22, 2010 at 2:03 PM, wrote: > On Fri, 22 Jan 2010 04:42:56 EST, Jeffrey Walton said: > > > > Very few people use Microsoft software because of its security > reputation. > > Presuming 'people' equates to Desktop installations, the numbers I > > have seen indicate otherwise. > > I think you misparsed what he said. You read it as "Because of its > security > reputation, very few people use Microsoft software". What he actually > meant > was "Very few people choose Microsoft with their security reputation as one > of the primary considerations". > > ___ > 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 - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [ MDVSA-2010:024 ] coreutils
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2010:024 http://www.mandriva.com/security/ ___ Package : coreutils Date: January 23, 2010 Affected: 2008.0, 2009.0, 2009.1, 2010.0, Corporate 4.0, Enterprise Server 5.0 ___ Problem Description: A vulnerability were discovered and corrected in coreutils: The distcheck rule in dist-check.mk in GNU coreutils 5.2.1 through 8.1 allows local users to gain privileges via a symlink attack on a file in a directory tree under /tmp (CVE-2009-4135). Packages for 2008.0 are provided for Corporate Desktop 2008.0 customers. The updated packages have been patched to correct this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4135 ___ Updated Packages: Mandriva Linux 2008.0: bbc5a0b5bfae7d1da7b497b40082dcc6 2008.0/i586/coreutils-6.9-5.1mdv2008.0.i586.rpm 4b41bae490d2c668412e6ab78676074e 2008.0/i586/coreutils-doc-6.9-5.1mdv2008.0.i586.rpm ceec0934e3ebe1816d55667c507008c6 2008.0/SRPMS/coreutils-6.9-5.1mdv2008.0.src.rpm Mandriva Linux 2008.0/X86_64: 5105b28b38878f141247d8b408467c4d 2008.0/x86_64/coreutils-6.9-5.1mdv2008.0.x86_64.rpm c9ddaa4146fceabf6224e4bbc7b5b214 2008.0/x86_64/coreutils-doc-6.9-5.1mdv2008.0.x86_64.rpm ceec0934e3ebe1816d55667c507008c6 2008.0/SRPMS/coreutils-6.9-5.1mdv2008.0.src.rpm Mandriva Linux 2009.0: 8c41d3f3f45657996085945a05a3ee1d 2009.0/i586/coreutils-6.12-2.5mdv2009.0.i586.rpm 1f01c000f74cca3d8ea80c80a5e77a77 2009.0/i586/coreutils-doc-6.12-2.5mdv2009.0.i586.rpm c0bfeba1f8803e84b0f19eda2dbcfc70 2009.0/SRPMS/coreutils-6.12-2.5mdv2009.0.src.rpm Mandriva Linux 2009.0/X86_64: 8d3fa8cf346205047b200e75e71a0f3b 2009.0/x86_64/coreutils-6.12-2.5mdv2009.0.x86_64.rpm 65f4ba201e1073044a5683ab5528f591 2009.0/x86_64/coreutils-doc-6.12-2.5mdv2009.0.x86_64.rpm c0bfeba1f8803e84b0f19eda2dbcfc70 2009.0/SRPMS/coreutils-6.12-2.5mdv2009.0.src.rpm Mandriva Linux 2009.1: 677a2e51fc24b865f50a9d246c3c47b6 2009.1/i586/coreutils-7.1-2.1mdv2009.1.i586.rpm 6ef52ebd79e343dd900c949efb2a72c1 2009.1/i586/coreutils-doc-7.1-2.1mdv2009.1.i586.rpm ea99205731c07360b5ba655ee3bbc3de 2009.1/SRPMS/coreutils-7.1-2.1mdv2009.1.src.rpm Mandriva Linux 2009.1/X86_64: 8d76e1e624c9c741569bb8e063cca8ab 2009.1/x86_64/coreutils-7.1-2.1mdv2009.1.x86_64.rpm 83a9d3e31bce5e465b84a730a6ff1fab 2009.1/x86_64/coreutils-doc-7.1-2.1mdv2009.1.x86_64.rpm ea99205731c07360b5ba655ee3bbc3de 2009.1/SRPMS/coreutils-7.1-2.1mdv2009.1.src.rpm Mandriva Linux 2010.0: a5595b72c83ada96d02a77ab8f899f44 2010.0/i586/coreutils-7.5-2.1mdv2010.0.i586.rpm cd3dd55d6071824c2ea70633ab222979 2010.0/i586/coreutils-doc-7.5-2.1mdv2010.0.i586.rpm ff13b7700b3c2133968e8910ea09911f 2010.0/SRPMS/coreutils-7.5-2.1mdv2010.0.src.rpm Mandriva Linux 2010.0/X86_64: 1b6e4154b358a5876ed80af38e8e978a 2010.0/x86_64/coreutils-7.5-2.1mdv2010.0.x86_64.rpm 9608a2886c7ef707b1df4183b894b3b4 2010.0/x86_64/coreutils-doc-7.5-2.1mdv2010.0.x86_64.rpm ff13b7700b3c2133968e8910ea09911f 2010.0/SRPMS/coreutils-7.5-2.1mdv2010.0.src.rpm Corporate 4.0: 09f9564f73c38994f7b7b86d817285f8 corporate/4.0/i586/coreutils-5.2.1-8.1.20060mlcs4.i586.rpm 7e5005893e4a2727e53fceb19db6ff8c corporate/4.0/i586/coreutils-doc-5.2.1-8.1.20060mlcs4.i586.rpm 0d9aad80fdd05f2eeffa7678b71f4aac corporate/4.0/SRPMS/coreutils-5.2.1-8.1.20060mlcs4.src.rpm Corporate 4.0/X86_64: 403f7d811c4c9b8822f0ab3f7cff683d corporate/4.0/x86_64/coreutils-5.2.1-8.1.20060mlcs4.x86_64.rpm 224927bf18cb5418b47d846b104bb34b corporate/4.0/x86_64/coreutils-doc-5.2.1-8.1.20060mlcs4.x86_64.rpm 0d9aad80fdd05f2eeffa7678b71f4aac corporate/4.0/SRPMS/coreutils-5.2.1-8.1.20060mlcs4.src.rpm Mandriva Enterprise Server 5: f877e344eb0908e073c3a854d12cadec mes5/i586/coreutils-6.12-2.5mdvmes5.i586.rpm d0cede58c64e7ff6d78dfef11276cec2 mes5/i586/coreutils-doc-6.12-2.5mdvmes5.i586.rpm f219918d16c0498311d1a486b282 mes5/SRPMS/coreutils-6.12-2.5mdvmes5.src.rpm Mandriva Enterprise Server 5/X86_64: 6286996ffa27c4606fe018ee4a686b76 mes5/x86_64/coreutils-6.12-2.5mdvmes5.x86_64.rpm 697ae5dbe6e1bf0b47bf84c0c0fa1c21 mes5/x86_64/coreutils-doc-6.12-2.5mdvmes5.x86_64.rpm f219918d16c0498311d1a486b282 mes5/SRPMS/coreutils-6.12-2.5mdvmes5.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG
Re: [Full-disclosure] FREE STEPHEN WATT !!!
Who cares. -- Founder/Activist http://fusecurity.com/ | "Free Security Technology" ___ 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] NSOADV-2010-002: Google Wave Design Bugs
is this really supposed to work? http://i45.tinypic.com/nds8lx.png I don't see much wrong here, isn't it doing exactly what it's supposed to do? Display the data given in the xml? -- Founder/Activist http://fusecurity.com/ | "Free Security Technology" ___ 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] Two MSIE 6.0/7.0 NULL pointer crashes
On Thu, 21 Jan 2010, Dan Kaminsky wrote: > But imagine an oldschool application drenched in strcpy, where you've > lost context of the length of that buffer five functions ago. When you discover you are riding a dead horse, the best strategy is to dismount. When you discover the program is designed too badly to be maintained, the best strategy is to rewrite it. > Or imagine the modern browser bug, where you're going up against an > attacker who *by design* has a Turing complete capability to manipulate > your object tree, complete with control over time. Such an attacker must be assumed to possess hyperturing computing power because an exploit can communicate with an oracle. But I do not think this case is much different from the previous one: most, if not all, of those bugs are elementary integrity violations (not prevented because the boundary between trusted and untrusted data is not clear enough) and race conditions (multithreading with locks is an idea on the same level as strcpy). > Or, worst of all, take a design flaw like Marsh Ray's TLS > renegotiation bug. One needs to pay utmost attention to the design and its correctness. This has been known for decades, hasn't it? (An interesting finding regarding the renegotiation issue: People analyzing the protocol in the past had spent a lot of energy on its individual parts, esp. the handshake, and very little work had been done on the protocol as a whole.) > c) The system needs to work entirely the same after. Not entirely. You want to get rid of the vulnerability. -- Pavel Kankovsky aka Peak / Jeremiah 9:21\ "For death is come up into our MS Windows(tm)..." \ 21st century edition / ___ 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] Two MSIE 6.0/7.0 NULL pointer crashes
On Sun, Jan 24, 2010 at 1:05 AM, Pavel Kankovsky wrote: > On Thu, 21 Jan 2010, Dan Kaminsky wrote: > >> But imagine an oldschool application drenched in strcpy, where you've >> lost context of the length of that buffer five functions ago. > > When you discover you are riding a dead horse, the best strategy is to > dismount. When you discover the program is designed too badly to be > maintained, the best strategy is to rewrite it. No question. And how long do you think that takes? Remember when Netscape decided to throw away the Navigator 4.5 codebase, in favor of Mozilla/Seamonkey? Remember how they had to do that *again* with Mozilla/Gecko? >> Or imagine the modern browser bug, where you're going up against an >> attacker who *by design* has a Turing complete capability to manipulate >> your object tree, complete with control over time. > > Such an attacker must be assumed to possess hyperturing computing power > because an exploit can communicate with an oracle. "Hyperturing computing power" Not really sure what that means, but yes, oracles are pretty damn useful. As Dino just pointed me to @ BHDC: == Dionysus Blazakis Interpreter Exploitation: Pointer Inference and JIT Spraying As remote exploits have dwindled and perimeter defenses have become the standard, remote client-side attacks are the next best choice for an attacker. Modern Windows operating systems have quelled the explosion of client-side vulnerabilities using mitigation techniques such as data execution prevention (DEP) and address space layout randomization (ASLR). This work will illustrate two novel techniques to bypass DEP and ASLR mitigations. These techniques leverage the attack surface exposed by the advanced script interpreters or virtual machines commonly accessible within the browser. The first technique, pointer inference, is used to find the memory address of a string of shellcode within the ActionScript interpreter despite ASLR. The second technique, JIT spraying, is used to write shellcode to executable memory by leveraging predictable behaviors of the ActionScript JIT compiler bypassing DEP. Future research directions and countermeasures for interpreter implementers are discussed. === > But I do not think this case is much different from the previous one: > most, if not all, of those bugs are elementary integrity violations (not > prevented because the boundary between trusted and untrusted data is not > clear enough) and race conditions (multithreading with locks is an > idea on the same level as strcpy). Nah, it's actually a lot worse. You have to start thinking in terms of state explosion -- having turing complete access to even some of the state of a remote system creates all sorts of new states that, even if *reachable* otherwise, would never be *predictably reachable*. I mean, use-after-free becomes ludicrously easier when you can grab a handle and cause a free. >> Or, worst of all, take a design flaw like Marsh Ray's TLS >> renegotiation bug. > > One needs to pay utmost attention to the design and its correctness. > This has been known for decades, hasn't it? Sure. But we're not talking about what should be done before you write. We're talking about what happens when you screw up. > (An interesting finding regarding the renegotiation issue: People > analyzing the protocol in the past had spent a lot of energy on its > individual parts, esp. the handshake, and very little work had been done > on the protocol as a whole.) Eh. This was a subtle one, based more on not realizing the semantics from one layer happened to match the semantics of another, and also not recognizing possible faults in the multi-session case. It's a pretty beautiful bug. >> c) The system needs to work entirely the same after. > > Not entirely. You want to get rid of the vulnerability. I wouldn't consider being vulnerable "working" :) But point taken. The system needs to meet its functional requirements entirely the same after. Yes, there are bugs that make this *enormously* difficult, where you need to force a major migration to make customers safe. Adobe pushed something like this through for the DNS Rebinding socket fixes, phasing the fix across multiple releases at pretty enormous expense. > -- > Pavel Kankovsky aka Peak / Jeremiah 9:21 \ > "For death is come up into our MS Windows(tm)..." \ 21st century edition / > > ___ > 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 - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
