Re: [Full-disclosure] Two MSIE 6.0/7.0 NULL pointer crashes
On Sun, 24 Jan 2010, Dan Kaminsky wrote: It took me more than one month to write this response? Ouch! 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? It depends. Probably in the order of several years for a big application. On the other hand, existing code is not always so bad one has to throw it out all and rewrite everything from the scratch in one giant step. 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? Mozilla (even the old Mozilla Application Suite known as Seamonkey today) has always been based on Gecko (aka new layout, NGLayout). The development of Gecko started in 1997 as an internal Netscape project. Old Netscape Communicator source (most of it) was released in March 1998. The decision not to use it was made in October 1998. Gecko source was released in December 1998. Mozilla 0.6 was released in December 2000, 0.9 in May 2001 and 1.0 in June 2002. This makes approximately 5 years. Firefox started as a mozilla/browser branch approximately in April 2002 (the idea is probably dating back to mid 2001). The first public version known as Phoenix 0.1 was released in September 2002, 0.9 was released in June 2004, 1.0 in November 2004. 2.5 years. To put thing into a broader perspective: MSIE 5.0 was released in March 1999, 6.0 in August 2001, 7.0 in October 2006, and 8.0 in March 2009. This makes 2.5 years from 5.0 to 6.0, 5 years to 7.0 and 2.5 years to 8.0. The development of Google Chrome is reported to have started in spring 2006 and 1.0 was released in December 2008. 2.5 years again (but they reused WebKit and other 3rd party components). Hyperturing computing power Not really sure what that means, The ability to solve problems of Turing degree [1] greater than zero. Superturing is probably a more common term although various terms starting with hyper- are used as well [2]. (Alternatively, it can relate to a certain kind of AIs in Orion's Arm universe [3] but that meaning is not relevant here. g) For the most part it is a purely theoretical notion but there is at least one kind of oracle that is more or less physically feasible: a hardware random number generator--such an oracle might look pointless but quite a lot of cryptography relies on the ability to generate numbers that cannot be guessed by an adversary. Anyway, real computer are not true Turing machines and they are not turing complete. The point of my comment, translated into a more realistic setting, is as follows: one must assume the attacker can wield much more computing power than the defender. [1] http://en.wikipedia.org/wiki/Turing_degree [2] http://en.wikipedia.org/wiki/Hypercomputation [3] http://www.orionsarm.com/eg-topic/45c54923c3496 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 dare to say it can make the analysis more complicated if the ill-defined difficulty of exploitation is taken into consideration. In many cases the ability to execute a predefined sequence of operations is everything you need to reach an arbitrary state of the system (from a known initial state). You do not need anything as strong as a Turing machine, even a finite state machine is too powerful, a single finite sequence of operations (or perhaps a finite set of them) is sufficient. I mean, use-after-free becomes ludicrously easier when you can grab a handle and cause a free. I admit use-after-free does not fit well into the two categories I mentioned. But it is still a straightforward violation of a simple property (do not deallocate memory as long as any references to it exist) and it is quite easy to avoid it (e.g. use a garbage collector). Sure. But we're not talking about what should be done before you write. We're talking about what happens when you screw up. I do not think it is reasonable to separate these two questions. After all people are supposed to learn from their mistakes and avoid them in the future. (An interesting finding regarding the renegotiation issue: [...] Eh. This was a subtle one, [...] I do not want to downplay the ingenuity of Marsh Ray and Steve Dispensa (and Martin Rex) but... Any attempt to formalize integrity properties SSL/TLS is supposed to guarantee would inevitably lead to something
Re: [Full-disclosure] Two MSIE 6.0/7.0 NULL pointer crashes
Sometimes the vulnerability itself is a functional requirement (or considered to be one of them). Has anyone mentioned ActiveX? Or NPAPI for the matter. Really, other then the automated-after-user-accept-installation they're both the same. On Sun, Feb 28, 2010 at 9:22 PM, Pavel Kankovsky p...@argo.troja.mff.cuni.cz wrote: On Sun, 24 Jan 2010, Dan Kaminsky wrote: It took me more than one month to write this response? Ouch! 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? It depends. Probably in the order of several years for a big application. On the other hand, existing code is not always so bad one has to throw it out all and rewrite everything from the scratch in one giant step. 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? Mozilla (even the old Mozilla Application Suite known as Seamonkey today) has always been based on Gecko (aka new layout, NGLayout). The development of Gecko started in 1997 as an internal Netscape project. Old Netscape Communicator source (most of it) was released in March 1998. The decision not to use it was made in October 1998. Gecko source was released in December 1998. Mozilla 0.6 was released in December 2000, 0.9 in May 2001 and 1.0 in June 2002. This makes approximately 5 years. Firefox started as a mozilla/browser branch approximately in April 2002 (the idea is probably dating back to mid 2001). The first public version known as Phoenix 0.1 was released in September 2002, 0.9 was released in June 2004, 1.0 in November 2004. 2.5 years. To put thing into a broader perspective: MSIE 5.0 was released in March 1999, 6.0 in August 2001, 7.0 in October 2006, and 8.0 in March 2009. This makes 2.5 years from 5.0 to 6.0, 5 years to 7.0 and 2.5 years to 8.0. The development of Google Chrome is reported to have started in spring 2006 and 1.0 was released in December 2008. 2.5 years again (but they reused WebKit and other 3rd party components). Hyperturing computing power Not really sure what that means, The ability to solve problems of Turing degree [1] greater than zero. Superturing is probably a more common term although various terms starting with hyper- are used as well [2]. (Alternatively, it can relate to a certain kind of AIs in Orion's Arm universe [3] but that meaning is not relevant here. g) For the most part it is a purely theoretical notion but there is at least one kind of oracle that is more or less physically feasible: a hardware random number generator--such an oracle might look pointless but quite a lot of cryptography relies on the ability to generate numbers that cannot be guessed by an adversary. Anyway, real computer are not true Turing machines and they are not turing complete. The point of my comment, translated into a more realistic setting, is as follows: one must assume the attacker can wield much more computing power than the defender. [1] http://en.wikipedia.org/wiki/Turing_degree [2] http://en.wikipedia.org/wiki/Hypercomputation [3] http://www.orionsarm.com/eg-topic/45c54923c3496 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 dare to say it can make the analysis more complicated if the ill-defined difficulty of exploitation is taken into consideration. In many cases the ability to execute a predefined sequence of operations is everything you need to reach an arbitrary state of the system (from a known initial state). You do not need anything as strong as a Turing machine, even a finite state machine is too powerful, a single finite sequence of operations (or perhaps a finite set of them) is sufficient. I mean, use-after-free becomes ludicrously easier when you can grab a handle and cause a free. I admit use-after-free does not fit well into the two categories I mentioned. But it is still a straightforward violation of a simple property (do not deallocate memory as long as any references to it exist) and it is quite easy to avoid it (e.g. use a garbage collector). Sure. But we're not talking about what should be done before you write. We're talking about what happens when you screw up. I do not think it is reasonable to separate these two questions. After all people are
Re: [Full-disclosure] Two MSIE 6.0/7.0 NULL pointer crashes
On 2/28/2010 2:22 PM, Pavel Kankovsky wrote: On Sun, 24 Jan 2010, Dan Kaminsky wrote: 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*. Perhaps it would be more proper to say that those states really did exist beforehand but were unrecognized? We could refer to them as latent states! Even the simplest static analysis should uncover the explosion caused by scanf(%s). The problem is that there are so many other ways that a combinatorial explosion of states can exceed the capacity of static analysis it can't tell the valid ones from the exploitable ones. If you make a static analysis product, I suspect your customers will want it to somehow run in bounded time and memory. I do not want to downplay the ingenuity of Marsh Ray and Steve Dispensa (and Martin Rex) but... Oh man. We should downplay those guys whenever we get the chance. :-) Pavel and Dan, truly it is you who instruct us by your example! Did you guys catch our talk at Shmoo 2010 yet? We've got to get that online somehow. Any attempt to formalize integrity properties SSL/TLS is supposed to guarantee would inevitably lead to something along the lines of all data sent/received by a server within the context of a certain session must have been received/sent by the same client. You know, I would have thought the same thing before I tried explaining it to various people in the industry. The weird thing is that the speed (and likelihood) of a person accepting the problem in TLS was (with notable exceptions) inversely proportional to the amount they knew about TLS and crypto in general. For example, a credentialed cryptographer we explained it to maintained that there was no problem with the crypto, just how we were using it. Many felt the bug was in https for retroactively authenticating in the first place. Check out the first comment at http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html And Ben Laurie's post at http://www.links.org/?p=789 The killer point for me in the debate is the part of the spec that says that app data can be interleaved in the handshake messages of the renegotiation. Without the assumption of continuity-of-identity, that creates a whole range of ambiguous states which are not properly defined. Thus the TLS spec is, in fact, internally inconsistent. But this is reeely subtle unless you've read the spec many times (even most implementers seem to ignore it). The world was previously divided into two camps: A. (The great majority) People who didn't realize SSLv3+TLS could renegotiate at all. It hadn't occurred to these people to question if it offered the same continuity-of-identity that we had with SSLv2. B. People who were intimately familiar with TLS and knew it could theoretically reneogtiate but hadn't looked at that minor footnote of the spec hard enough (after all, it was thought to be rarely used and already encrypted). And I find it rather unplausible the problem with renegotiations would avoid detection if those properties were checked thoroughly. But the need for stating explicitly and double-checking such an obvious requirement might not have even come up. After all, it had not been explicitly checked for in various other security reviews over the years. Certainly some of those reviewers had been familiar with http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.8510 Man-in-the-Middle in Tunnelled Authentication Protocols (2002) N. Asokan, Valtteri Niemi, Kaisa Nyberg where a similar attack was described. What would have done it (I think) is if they had looked at how the APIs were defined and used by applications. Then they would have seen that the APIs remained the same from SSLv2 even as SSLv3 added a whole nother layer of abstraction through this renegotiation facility. - Marsh ___ 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 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, valdis.kletni...@vt.edu 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/
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 p...@argo.troja.mff.cuni.cz 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/
Re: [Full-disclosure] Two MSIE 6.0/7.0 NULL pointer crashes
Given Microsoft's already poor reputation regarding security, I'm not sure how it'd be possible for them to degrade their reputation any more I don't believe its as bad as you think since Microsoft adopted a SDLC (prior to circa 2001 was a different story). I also believe a significant portion of the perception is due to vendors running on a Windows operating system. When is the last time you heard someone bashing Adobe, which is currently 'King of the Vulnerability Hill.'? Adobe surpasses Microsoft as favorite hacker’s target (Jul 2009) http://lastwatchdog.com/adobe-surpasses-microsoft-favorite-hackers-target/ Adobe predicted as top 2010 hacker target (Dec 2009) http://www.theregister.co.uk/2009/12/29/security_predictions_2010/. You're probably not going to like this, but in 2003, Apache on Linux over took IIS as most defaced (the Server market share between Windows and *nix appears to be about equal - see below). Zone-H Statistics Report, http://www.zone-h.org/news/id/4686 I'm not sticking up for Microsoft. I simply claim the numbers state otherwise. Very few people use Microsoft software because of its security reputation. Presuming 'people' equates to Desktop installations, the numbers I have seen indicate otherwise. When estimated through browser use, Microsoft appears to have about 90%. Personally, I am familiar with two US federal agencies where the desktop is exclusively Microsoft (about 160,000 total hosts combined, unless the US government has downsized since 2006). If you're talking about servers, the numbers indicate that Microsoft is on par with *nix (IDC report) or slightly above *nix (Gartner report). Again, I'm not sticking up for Microsoft. I simply claim the numbers state otherwise. The main reasons for using Microsoft are ease of use and compatibility with other users. Is *nix not trying to do the same? These are two key factors which *must* be fulfilled before *nix can displace Microsoft on the Desktop. IT departments like 'easy to use' - it keeps help desk calls to a minimum. IT departments also like compatibility since they don't have to spend time researching problems, workarounds, and solutions. Given that, I'm not sure that Microsoft's perception will be affected very much in the user community. Agreed. I do question Microsoft's position on *not* patching flaws when discovered or reported in a timely manner. But that's another story, and brings in co-conspirators, such as iDefense and TippingPoint. For example, CVE-2009-2502 was reported to Microsoft in 2007 by a firm which buys bugs to save everyone from 0-days. Microsoft probably knew about the 2502 bug earlier, since the GDI+/JPEG vuln was made public in Microsoft Security Bulletin MS04-028 (I'm making the leap that Microsoft performed additional audits on the GDI+ module when reports started arriving). Yet the bug was not fixed until 2009 (almost 2 years). See http://seclists.org/fulldisclosure/2009/Oct/196. ~JW On Thu, Jan 21, 2010 at 6:34 PM, Rohit Patnaik quanti...@gmail.com wrote: Given Microsoft's already poor reputation regarding security, I'm not sure how it'd be possible for them to degrade their reputation any more. Very few people use Microsoft software because of its security reputation. The main reasons for using Microsoft are ease of use and compatibility with other users. Given that, I'm not sure that Microsoft's perception will be affected very much in the user community. -- Rohit Patnaik On Wed, Jan 20, 2010 at 6:17 PM, ☣ frank^2 fra...@dc949.org wrote: On Wed, Jan 20, 2010 at 10:25 AM, Dan Kaminsky d...@doxpara.com wrote: Seriously. I mean, just look at Linux, Firefox, and OpenOffice. Pristine code, not a single security vulnerability between them :) That's a red herring. His point was the public perception of the software company-- true or not-- would be hindered because Microsoft is all-encompassing. Compared to the world of open-source, the risk is distributed by the sheer virtue of software engineering being distributed amongst thousands of entities. This means that the vulnerabilities are spread across different parties, rather than having all vulnerabilities encompassed by a single party-- in this case, Microsoft. His argument was irrelevant to corporations vs. open-source being more vulnerable than one another-- it was simply a commentary on distributed risk in software engineering. -- Did you and them get your degree from the same university of trolls? I have mistaken nothing for nothing. Fuck 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/ ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michal Zalewski wrote: Testing takes time. That's why both Microsoft and Mozilla test. Testing almost never legitimately takes months or years, unless the process is severely broken; contrary to the popular claims, personally, I have serious doubts that QA is a major bottleneck when it comes to security response - certainly not as often as portrayed. The generalization made earlier in this thread - that closed source projects are always bad when it comes to security response, while the open source community is inherently responsive - does not even deserve a proper rebuttal. I am cc:ed on quite a few open security bugs in major open source software - and when a problem is kept under wraps, it is not unheard of to wait 6-12 months for a fix. Both in the open source and in the closed source world, the real story is almost always that the security issues you report need to be prioritized against hundreds of other internally discovered security problems; and thousands of high-priority but non-security bugs that affect market adoption or annoy key customers. On top of this, many security changes may require significant rewrites that the vendor is hesitant to implement because of having no resources or no long-term plan to do so. In other words, in many cases, most of the waiting period is a prolonged no-op that may serves no legitimate function, and may be putting users at an unreasonable risk. Even without assuming malice on the side of the vendor, this demonstrates an inherent weakness of the responsible disclosure process (understood as accepting arbitrary vendor-provided disclosure timelines): while some vendors are quite willing to give security issues top priority, and will actually work to get things done - others may exploit the rhetoric to mask staffing problems or the inability to drive engineering decisions effectively. Cheers, /mz Thank you for the insights Michal. I accept my comment was a little glib, however it has been my experience that open source vulnerabilities of this magnitude that are in the wild are usually fixed in a day or two by the OS community whereas large closed source developers can take weeks or longer to release a fix for such flaws. Perhaps this is due, at least in part, to the modularity and separation of function in OSS and being able to a personally identify the developer of a vulnerable OS project. Also a single person or small team can act more efficiently on known code. Where as in a large corporate closed software development environment where an application carries so many dependencies on evolving and legacy code, where the person responsible for introducing the vulnerability is not publicly identifiable can lead to all kinds of denial, excuses and buck passing. Perhaps I am a little naive, after all I am a novice in this field which I am not afraid to admit. But it seems to me with large closed source projects developed in commercial corporate environments the object of the exercise is to get product out first regardless of the quality of the released code. And only if a vulnerability is a threat to adoption of a product is that vulnerability dealt with in a timely fashion. regards mrx - -- Mankind's systems are white sticks tapping walls. Thanks Roy http://www.propergander.org.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBS1ge1rIvn8UFHWSmAQIJyQf+KXxLSS1/UOi0oRlFE3+5O9tMifKUMDMu qasl2DPQVxV3gj81D2J8Skzmv7ixgQpL7/kSprrX48XdhQjKvohEzaR32mJVrtba t3njHWaf0fEUWBkTajGmpVtDvn+dnC86Y6cFNs3W8bWeKFX1d5uBdlPDeoNQrtSL TPIqQPWX2zaEHDwZe2AD8Qi7RccBP5SQUy+ilmQJ/USiWI9DlFcXTf7OYT/Y4RGD t9a5w420YJQyrbCHWWd8WI0vrMGAYPb9oWJphrPrxaw7AvWqkwcQSA4EdMpEaPww YIrcH5XriNFy//A6Fpc6/4r9OUWEeEy3sZmG54gXahFWRl1rjc62aw== =eMUR -END 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
On Thu, Jan 21, 2010 at 1:53 AM, Michal Zalewski lcam...@coredump.cx wrote: Testing takes time. That's why both Microsoft and Mozilla test. Testing almost never legitimately takes months or years, unless the process is severely broken; contrary to the popular claims, personally, I have serious doubts that QA is a major bottleneck when it comes to security response - certainly not as often as portrayed. There are a lot of factors that go into how long it takes to run QA. Here's a few (I'll leave out the joys of multivendor for now): 1) How widespread is the deployment? A little while ago, Google had an XSS on Google Maps. An hour later, they didn't. About a decade ago, AOL Instant Messenger had a remote code execution vulnerability. Eight hours later, they didn't. Say what you will about centralization, but it *really* makes it easier and safer to deploy a fix, because the environment is totally known, and you have only one environment. There are a couple dimensions at play here: a) How many versions do you need to patch? b) How many different deployment classes are there? If your developers are making a bunch of enterprise assumptions (there's a domain, there's group policy, there's an IT guy, etc) and the fix is going to Grandma, let me tell you, something's not going to work c) What's at stake? Your D-Link router has very different deployment characteristics than your Juniper router. 2) How complicated is the fix? Throwing in a one-liner to make sure an integer doesn't overflow is indeed relatively straightforward. But imagine an oldschool application drenched in strcpy, where you've lost context of the length of that buffer five functions ago. 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. Or, worst of all, take a design flaw like Marsh Ray's TLS renegotiation bug. People are still fiddling around with figuring out how to fix that bug right, months later. Complexity introduces three issues: a) You have to fix the entire flaw, and related flaws. We've all seen companies who deploy fixes like if this argument contains alert(1), abort. Yeah, that's not enough. b) You have to not introduce new flaws with your fix -- complexity doesn't stop increasing vulnerability just because you're doing a security fix. c) The system needs to work entirely the same after. That means you don't get to significantly degrade performance, usability, reliability, or especially compatibility. Particularly with design bugs, other systems grow to depend on their presence. No software lives in a vacuum, so you have to actually _find_ these other pieces of code, and make sure things still work. 3) How many people do you actually expect to deploy your patch? There's this entire continuum between only the other developers on SVN, through the people who call to complain, to everybody who clicks 'I accept the risk of patching', to my entire customer base with zero user interaction whatsoever. A patch with problems 0.005% of the time is acceptable if 1000 people are deploying, but not if 1,000,000 people are deploying. Note that security research is very strongly correlated with deployment numbers, to the point that vulnerability count is much more correlated with popularity than code quality. So you have this interesting situation where the more your fix is pushed, the more scrutiny there will be upon it. Now, you can consider these all excuses. Believe me, QA people have no shortage of guys who look down on them and their problems. But certainly different bugs have different characteristics, and assuming that all things can be fixed in the same time window with the same output quality is just factually untrue. You might as well be claiming the next version of HTML5 will include an antigravity tag that will make your laptop float in the air and spin around. There is a balancing act. Years is, of course, ridiculous. In many situations, so too are a couple of weeks. If the goal is to achieve the best quality patches, then you want the issue _prioritized heavily_, but not _on public fire_. The latter encourages people to skip testing, and you know of course what happens when you skip testing? You end up with Gigabit Ethernet drivers that can't actually handle all frame lengths. (Epic Intel find from Fabian Yamaguchi. Wow.) Responsible disclosure has its risks. You really can be jerked around by a company, *especially* one that hasn't experienced the weirdness of an external security disclosure before. But engineering realities don't go away just because the suits finally got out of the way. Testing matters. ___ 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
People are unreasonable, first they complain about lack of quick patches/fixes. Next they complain about fixes crashing their system. Regards, Chris. On Thu, Jan 21, 2010 at 5:12 PM, Dan Kaminsky d...@doxpara.com wrote: On Thu, Jan 21, 2010 at 1:53 AM, Michal Zalewski lcam...@coredump.cx wrote: Testing takes time. That's why both Microsoft and Mozilla test. Testing almost never legitimately takes months or years, unless the process is severely broken; contrary to the popular claims, personally, I have serious doubts that QA is a major bottleneck when it comes to security response - certainly not as often as portrayed. There are a lot of factors that go into how long it takes to run QA. Here's a few (I'll leave out the joys of multivendor for now): 1) How widespread is the deployment? A little while ago, Google had an XSS on Google Maps. An hour later, they didn't. About a decade ago, AOL Instant Messenger had a remote code execution vulnerability. Eight hours later, they didn't. Say what you will about centralization, but it *really* makes it easier and safer to deploy a fix, because the environment is totally known, and you have only one environment. There are a couple dimensions at play here: a) How many versions do you need to patch? b) How many different deployment classes are there? If your developers are making a bunch of enterprise assumptions (there's a domain, there's group policy, there's an IT guy, etc) and the fix is going to Grandma, let me tell you, something's not going to work c) What's at stake? Your D-Link router has very different deployment characteristics than your Juniper router. 2) How complicated is the fix? Throwing in a one-liner to make sure an integer doesn't overflow is indeed relatively straightforward. But imagine an oldschool application drenched in strcpy, where you've lost context of the length of that buffer five functions ago. 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. Or, worst of all, take a design flaw like Marsh Ray's TLS renegotiation bug. People are still fiddling around with figuring out how to fix that bug right, months later. Complexity introduces three issues: a) You have to fix the entire flaw, and related flaws. We've all seen companies who deploy fixes like if this argument contains alert(1), abort. Yeah, that's not enough. b) You have to not introduce new flaws with your fix -- complexity doesn't stop increasing vulnerability just because you're doing a security fix. c) The system needs to work entirely the same after. That means you don't get to significantly degrade performance, usability, reliability, or especially compatibility. Particularly with design bugs, other systems grow to depend on their presence. No software lives in a vacuum, so you have to actually _find_ these other pieces of code, and make sure things still work. 3) How many people do you actually expect to deploy your patch? There's this entire continuum between only the other developers on SVN, through the people who call to complain, to everybody who clicks 'I accept the risk of patching', to my entire customer base with zero user interaction whatsoever. A patch with problems 0.005% of the time is acceptable if 1000 people are deploying, but not if 1,000,000 people are deploying. Note that security research is very strongly correlated with deployment numbers, to the point that vulnerability count is much more correlated with popularity than code quality. So you have this interesting situation where the more your fix is pushed, the more scrutiny there will be upon it. Now, you can consider these all excuses. Believe me, QA people have no shortage of guys who look down on them and their problems. But certainly different bugs have different characteristics, and assuming that all things can be fixed in the same time window with the same output quality is just factually untrue. You might as well be claiming the next version of HTML5 will include an antigravity tag that will make your laptop float in the air and spin around. There is a balancing act. Years is, of course, ridiculous. In many situations, so too are a couple of weeks. If the goal is to achieve the best quality patches, then you want the issue _prioritized heavily_, but not _on public fire_. The latter encourages people to skip testing, and you know of course what happens when you skip testing? You end up with Gigabit Ethernet drivers that can't actually handle all frame lengths. (Epic Intel find from Fabian Yamaguchi. Wow.) Responsible disclosure has its risks. You really can be jerked around by a company, *especially* one that hasn't experienced the weirdness of an external security disclosure before. But engineering realities don't go away just
Re: [Full-disclosure] Two MSIE 6.0/7.0 NULL pointer crashes
Given Microsoft's already poor reputation regarding security, I'm not sure how it'd be possible for them to degrade their reputation any more. Very few people use Microsoft software because of its security reputation. The main reasons for using Microsoft are ease of use and compatibility with other users. Given that, I'm not sure that Microsoft's perception will be affected very much in the user community. -- Rohit Patnaik On Wed, Jan 20, 2010 at 6:17 PM, ☣ frank^2 fra...@dc949.org wrote: On Wed, Jan 20, 2010 at 10:25 AM, Dan Kaminsky d...@doxpara.com wrote: Seriously. I mean, just look at Linux, Firefox, and OpenOffice. Pristine code, not a single security vulnerability between them :) That's a red herring. His point was the public perception of the software company-- true or not-- would be hindered because Microsoft is all-encompassing. Compared to the world of open-source, the risk is distributed by the sheer virtue of software engineering being distributed amongst thousands of entities. This means that the vulnerabilities are spread across different parties, rather than having all vulnerabilities encompassed by a single party-- in this case, Microsoft. His argument was irrelevant to corporations vs. open-source being more vulnerable than one another-- it was simply a commentary on distributed risk in software engineering. -- Did you and them get your degree from the same university of trolls? I have mistaken nothing for nothing. Fuck 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/ ___ 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, Jan 21, 2010 at 11:22 AM, Christian Sciberras uuf6...@gmail.com wrote: People are unreasonable, first they complain about lack of quick patches/fixes. Next they complain about fixes crashing their system. You're right - Corporate America needs to find more folks willing to accept unpatched software that crashes their system. Its hard to justify big bonuses when a company is run into the ground (wait - no its not. Disregard.) On Thu, Jan 21, 2010 at 5:12 PM, Dan Kaminsky d...@doxpara.com wrote: On Thu, Jan 21, 2010 at 1:53 AM, Michal Zalewski lcam...@coredump.cx wrote: Testing takes time. That's why both Microsoft and Mozilla test. Testing almost never legitimately takes months or years, unless the process is severely broken; contrary to the popular claims, personally, I have serious doubts that QA is a major bottleneck when it comes to security response - certainly not as often as portrayed. There are a lot of factors that go into how long it takes to run QA. Here's a few (I'll leave out the joys of multivendor for now): [SNIP] ___ 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] Two MSIE 6.0/7.0 NULL pointer crashes
Two NULL pointer crashes, they do not affect MSIE 8.0. Repros can be found here: http://skypher.com/index.php/2010/01/20/microsoft-internet-explorer-6-07-0-null-pointer-crashes/ Cheers, SkyLined http://skypher.com/index.php/2010/01/20/microsoft-internet-explorer-6-07-0-null-pointer-crashes/ Berend-Jan Wever berendjanwe...@gmail.com http://skypher.com/SkyLined ___ 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 my IE6 this doesn't work (crash), but it does on IE7. I'm on WinXP Pro SP3 DEP+. On Wed, Jan 20, 2010 at 11:57 AM, Berend-Jan Wever berendjanwe...@gmail.com wrote: Two NULL pointer crashes, they do not affect MSIE 8.0. Repros can be found here: http://skypher.com/index.php/2010/01/20/microsoft-internet-explorer-6-07-0-null-pointer-crashes/ Cheers, SkyLined http://skypher.com/index.php/2010/01/20/microsoft-internet-explorer-6-07-0-null-pointer-crashes/ Berend-Jan Wever berendjanwe...@gmail.com http://skypher.com/SkyLined ___ 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/
Re: [Full-disclosure] Two MSIE 6.0/7.0 NULL pointer crashes
Why doesn't microsoft throw some of it's weight behind Mozilla and ditch IE forever. It doesn't suit their image. On Wed, Jan 20, 2010 at 6:30 AM, Christian Sciberras uuf6...@gmail.comwrote: On my IE6 this doesn't work (crash), but it does on IE7. I'm on WinXP Pro SP3 DEP+. On Wed, Jan 20, 2010 at 11:57 AM, Berend-Jan Wever berendjanwe...@gmail.com wrote: Two NULL pointer crashes, they do not affect MSIE 8.0. Repros can be found here: http://skypher.com/index.php/2010/01/20/microsoft-internet-explorer-6-07-0-null-pointer-crashes/ Cheers, SkyLined http://skypher.com/index.php/2010/01/20/microsoft-internet-explorer-6-07-0-null-pointer-crashes/ Berend-Jan Wever berendjanwe...@gmail.com http://skypher.com/SkyLined ___ 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/ -- http://www.astorandblack.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/
Re: [Full-disclosure] Two MSIE 6.0/7.0 NULL pointer crashes
Sharepoint On Wed, Jan 20, 2010 at 9:38 AM, James Matthews nytrok...@gmail.com wrote: Why doesn't microsoft throw some of it's weight behind Mozilla and ditch IE forever. It doesn't suit their image. On Wed, Jan 20, 2010 at 6:30 AM, Christian Sciberras uuf6...@gmail.comwrote: On my IE6 this doesn't work (crash), but it does on IE7. I'm on WinXP Pro SP3 DEP+. On Wed, Jan 20, 2010 at 11:57 AM, Berend-Jan Wever berendjanwe...@gmail.com wrote: Two NULL pointer crashes, they do not affect MSIE 8.0. Repros can be found here: http://skypher.com/index.php/2010/01/20/microsoft-internet-explorer-6-07-0-null-pointer-crashes/ Cheers, SkyLined http://skypher.com/index.php/2010/01/20/microsoft-internet-explorer-6-07-0-null-pointer-crashes/ Berend-Jan Wever berendjanwe...@gmail.com http://skypher.com/SkyLined ___ 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/ -- http://www.astorandblack.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 - 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 Wed, 20 Jan 2010 10:38:34 EST, James Matthews said: Why doesn't microsoft throw some of it's weight behind Mozilla and ditch IE forever. It doesn't suit their image. Unfortunately, the PR doesn't work that way. Do you really want to be buying an entire operating system from somebody who just admitted they can't even produce a workable browser with all their resources? (Note this works differently in the Linux world, where the kernel crew doesn't even pretend to write browsers, and the Firefox crew *just* does browsers, and somebody else *just* does OpenOffice, and distros (for the most part) just worry about integration issues, and everybody only claims to do their little part well) pgpal3wBn1j10.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
Do you really want to be buying an entire operating system from somebody who just admitted they can't even produce a workable browser with all their resources? Valdis makes the novice assumption that people consider valuations of this sort when buying the newest iteration of Microsoft products. The idea that consumers would actually consider an alternative to what is an effectively locked in platform is laughable. The suggestion that they might find such a move to be of any relevance or impact on their purchasing decision is insane. On Wed, Jan 20, 2010 at 1:00 PM, valdis.kletni...@vt.edu wrote: On Wed, 20 Jan 2010 10:38:34 EST, James Matthews said: Why doesn't microsoft throw some of it's weight behind Mozilla and ditch IE forever. It doesn't suit their image. Unfortunately, the PR doesn't work that way. Do you really want to be buying an entire operating system from somebody who just admitted they can't even produce a workable browser with all their resources? (Note this works differently in the Linux world, where the kernel crew doesn't even pretend to write browsers, and the Firefox crew *just* does browsers, and somebody else *just* does OpenOffice, and distros (for the most part) just worry about integration issues, and everybody only claims to do their little part well) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- FD1D E574 6CAB 2FAF 2921 F22E B8B7 9D0D 99FF A73C http://pgp.mit.edu:11371/pks/lookup?search=tbiehnop=indexfingerprint=on http://pastebin.com/f6fd606da ___ 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 Wed, Jan 20, 2010 at 7:00 PM, valdis.kletni...@vt.edu wrote: On Wed, 20 Jan 2010 10:38:34 EST, James Matthews said: Why doesn't microsoft throw some of it's weight behind Mozilla and ditch IE forever. It doesn't suit their image. Unfortunately, the PR doesn't work that way. Do you really want to be buying an entire operating system from somebody who just admitted they can't even produce a workable browser with all their resources? (Note this works differently in the Linux world, where the kernel crew doesn't even pretend to write browsers, and the Firefox crew *just* does browsers, and somebody else *just* does OpenOffice, and distros (for the most part) just worry about integration issues, and everybody only claims to do their little part well) Seriously. I mean, just look at Linux, Firefox, and OpenOffice. Pristine code, not a single security vulnerability between them :) ___ 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
Yeah. Right. Right. In your dreams, my friend. Speaking of Firefox and open source software, firefox crashes once in an hour (and even more with flash in it). I'm developing an app for linux, the PC at work can't run a single version of linux (I tried the major 4 distros namely, ubuntu, fedora, suse and knoppix) each of which didn't work do to different but equally degrading bugs. On Wed, Jan 20, 2010 at 7:25 PM, Dan Kaminsky d...@doxpara.com wrote: On Wed, Jan 20, 2010 at 7:00 PM, valdis.kletni...@vt.edu wrote: On Wed, 20 Jan 2010 10:38:34 EST, James Matthews said: Why doesn't microsoft throw some of it's weight behind Mozilla and ditch IE forever. It doesn't suit their image. Unfortunately, the PR doesn't work that way. Do you really want to be buying an entire operating system from somebody who just admitted they can't even produce a workable browser with all their resources? (Note this works differently in the Linux world, where the kernel crew doesn't even pretend to write browsers, and the Firefox crew *just* does browsers, and somebody else *just* does OpenOffice, and distros (for the most part) just worry about integration issues, and everybody only claims to do their little part well) Seriously. I mean, just look at Linux, Firefox, and OpenOffice. Pristine code, not a single security vulnerability between them :) ___ 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/
Re: [Full-disclosure] Two MSIE 6.0/7.0 NULL pointer crashes
I'm developing an app for linux, the PC at work can't run a single version of linux Post a copy of lspci -v and I bet somebody proves you wrong. Cheers, Michael Holstein Cleveland State University ___ 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 Wed, Jan 20, 2010 at 10:25 AM, Dan Kaminsky d...@doxpara.com wrote: On Wed, Jan 20, 2010 at 7:00 PM, valdis.kletni...@vt.edu wrote: On Wed, 20 Jan 2010 10:38:34 EST, James Matthews said: Why doesn't microsoft throw some of it's weight behind Mozilla and ditch IE forever. It doesn't suit their image. Unfortunately, the PR doesn't work that way. Do you really want to be buying an entire operating system from somebody who just admitted they can't even produce a workable browser with all their resources? (Note this works differently in the Linux world, where the kernel crew doesn't even pretend to write browsers, and the Firefox crew *just* does browsers, and somebody else *just* does OpenOffice, and distros (for the most part) just worry about integration issues, and everybody only claims to do their little part well) Seriously. I mean, just look at Linux, Firefox, and OpenOffice. Pristine code, not a single security vulnerability between them :) Any complicated and evolving piece of software will have security vulnerabilities all the time. Maybe comparing and contrasting response to vulnerabilities would be interesting? Cheers Chris ___ 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/
Re: [Full-disclosure] Two MSIE 6.0/7.0 NULL pointer crashes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Evans wrote: On Wed, Jan 20, 2010 at 10:25 AM, Dan Kaminsky d...@doxpara.com wrote: On Wed, Jan 20, 2010 at 7:00 PM, valdis.kletni...@vt.edu wrote: On Wed, 20 Jan 2010 10:38:34 EST, James Matthews said: Why doesn't microsoft throw some of it's weight behind Mozilla and ditch IE forever. It doesn't suit their image. Unfortunately, the PR doesn't work that way. Do you really want to be buying an entire operating system from somebody who just admitted they can't even produce a workable browser with all their resources? (Note this works differently in the Linux world, where the kernel crew doesn't even pretend to write browsers, and the Firefox crew *just* does browsers, and somebody else *just* does OpenOffice, and distros (for the most part) just worry about integration issues, and everybody only claims to do their little part well) Seriously. I mean, just look at Linux, Firefox, and OpenOffice. Pristine code, not a single security vulnerability between them :) Any complicated and evolving piece of software will have security vulnerabilities all the time. Maybe comparing and contrasting response to vulnerabilities would be interesting? Cheers Chris Microsoft response: Shrug, oh wait a minute does this vulnerability effect our bottom line? OSS community response: We're on it, a fix will be available asap. Any complicated and evolving piece of software will have security vulnerabilities all the time. Quoted for truth. your evolving novice mrx - -- Mankind's systems are white sticks tapping walls. Thanks Roy http://www.propergander.org.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBS1dwibIvn8UFHWSmAQI7dQgAqzXcg+BBD7PyKUZWJvkTDb8WTIdLdHPz eF81z+gnSVFle2GkDIKA4AyLLfMAWuo3kQR1jxqWT131szlT1PSr4jYrbo8nBu0q OQe7tNKNdcUc2MUInzWC8YTsIlWqCASZXbL/2xvT4h+OdLh/kGjIVS1fnxpsPdBH Yl/DEjkFn0RjRkoDY/GdEKIe0b7JZjf8fYdSoj95dqAA3HdV7/QTiIaUdepTrsyh wGYl1aIJaY+NdMg9clEG3gMeYabhuF7RU3vqFGqjmaAd9D8WIXNA/miZsEB3YHqK FrNWjYb/gEDvzgfUSR4W5ek7OrATDmpvtqWjyD2lM+QshOXBo6UZNA== =m1O7 -END 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
Microsoft response: Shrug, oh wait a minute does this vulnerability effect our bottom line? OSS community response: We're on it, a fix will be available asap. Testing takes time. That's why both Microsoft and Mozilla test. A fix being *available* and a fix being *deployable* are not at all the same things. Just pull the latest build from SVN is rather noticeably not an option. Any complicated and evolving piece of software will have security vulnerabilities all the time. Quoted for truth. More accurate: Any complicated piece of software on an active attack surface will have software vulnerabilities found. There's a lot of projects that stopped evolving, but still have hidden vulns. ___ 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
Fuck yeah. Mozilla would be able to hire a few more developers, excellent! I've always felt that they're held back by an overly small development team - while this results in a clean, stable, fast browser, it means they can't support enough other stuff :( Oh... wait... 2010/1/21 James Matthews nytrok...@gmail.com Why doesn't microsoft throw some of it's weight behind Mozilla and ditch IE forever. It doesn't suit their image. On Wed, Jan 20, 2010 at 6:30 AM, Christian Sciberras uuf6...@gmail.comwrote: On my IE6 this doesn't work (crash), but it does on IE7. I'm on WinXP Pro SP3 DEP+. On Wed, Jan 20, 2010 at 11:57 AM, Berend-Jan Wever berendjanwe...@gmail.com wrote: Two NULL pointer crashes, they do not affect MSIE 8.0. Repros can be found here: http://skypher.com/index.php/2010/01/20/microsoft-internet-explorer-6-07-0-null-pointer-crashes/ Cheers, SkyLined http://skypher.com/index.php/2010/01/20/microsoft-internet-explorer-6-07-0-null-pointer-crashes/ Berend-Jan Wever berendjanwe...@gmail.com http://skypher.com/SkyLined ___ 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/ -- http://www.astorandblack.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 - 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
It appears Mozilla has the resources to hire additional staff as required [1]. Perhaps Mozilla needs a few Wall Street/Harvard School of Business MBAs in their accounting department. On more developers (perhaps things have changed a bit): Another interesting item in the report is the fact that Mozilla expenses were up in 2007 by 68 percent over 2006. Approximately 80 percent of Mozilla's expenses come from its staffing costs. What makes this really interesting is that Mozilla even with more paid staffers is still getting the same proportion of its code from external (i.e non-Mozilla) contributions. [2] And The percentage of code contributed to Firefox by people not employed by Mozilla remained steady at about 40 percent of the product we ship [2] [1] http://tech.slashdot.org/article.pl?sid=08/11/20/1327240 [2] http://blog.internetnews.com/skerner/2008/11/mozilla-revenues-hit-75-millio.html On Wed, Jan 20, 2010 at 5:36 PM, dramacrat yirim...@gmail.com wrote: Fuck yeah. Mozilla would be able to hire a few more developers, excellent! I've always felt that they're held back by an overly small development team - while this results in a clean, stable, fast browser, it means they can't support enough other stuff :( Oh... wait... 2010/1/21 James Matthews nytrok...@gmail.com Why doesn't microsoft throw some of it's weight behind Mozilla and ditch IE forever. It doesn't suit their image. On Wed, Jan 20, 2010 at 6:30 AM, Christian Sciberras uuf6...@gmail.com wrote: On my IE6 this doesn't work (crash), but it does on IE7. I'm on WinXP Pro SP3 DEP+. [SNIP] ___ 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
Date: Wed, 20 Jan 2010 19:25:11 +0100 From: Dan Kaminsky d...@doxpara.com Subject: Re: [Full-disclosure] Two MSIE 6.0/7.0 NULL pointer crashes To: valdis.kletni...@vt.edu Cc: Full-disclosure full-disclosure@lists.grok.org.uk Message-ID: f26cd0911001201025g7085cfe0t7b3fa4cb055ec...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 20, 2010 at 7:00 PM, valdis.kletni...@vt.edu wrote: On Wed, 20 Jan 2010 10:38:34 EST, James Matthews said: Why doesn't microsoft throw some of it's weight behind Mozilla and ditch IE forever. It doesn't suit their image. Unfortunately, the PR doesn't work that way. ?Do you really want to be buying an entire operating system from somebody who just admitted they can't even produce a workable browser with all their resources? (Note this works differently in the Linux world, where the kernel crew doesn't even pretend to write browsers, and the Firefox crew *just* does browsers, and somebody else *just* does OpenOffice, and distros (for the most part) just worry about integration issues, and everybody only claims to do their little part well) Seriously. I mean, just look at Linux, Firefox, and OpenOffice. Pristine code, not a single security vulnerability between them :) Well, there are vulnerabilities in Linux, FF and OpenOffice but these are not much covered in media compared to MS products. One main reason for this is that unless it is in kernel or a default suid application etc, -eventought it is open source- it will require significant amount of skills (more than you need on win) to exploit these vulns for beneficial purposes due to solid architecture of unix and variants.I am not saying open-source folks are doing a bad job (actually I believe they rock) but your comment leaves an impression like they have flawless quality of code and this is the only reason there are less vulnerabilities in these platforms. There are undisclosed vulnerabilities in the latest kernel and also in Firefox but they are *most likely* not used in criminal activities and etc - which is keeping them low/medium profile (even if they go public, statistical data) ___ 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
Testing takes time. That's why both Microsoft and Mozilla test. Testing almost never legitimately takes months or years, unless the process is severely broken; contrary to the popular claims, personally, I have serious doubts that QA is a major bottleneck when it comes to security response - certainly not as often as portrayed. The generalization made earlier in this thread - that closed source projects are always bad when it comes to security response, while the open source community is inherently responsive - does not even deserve a proper rebuttal. I am cc:ed on quite a few open security bugs in major open source software - and when a problem is kept under wraps, it is not unheard of to wait 6-12 months for a fix. Both in the open source and in the closed source world, the real story is almost always that the security issues you report need to be prioritized against hundreds of other internally discovered security problems; and thousands of high-priority but non-security bugs that affect market adoption or annoy key customers. On top of this, many security changes may require significant rewrites that the vendor is hesitant to implement because of having no resources or no long-term plan to do so. In other words, in many cases, most of the waiting period is a prolonged no-op that may serves no legitimate function, and may be putting users at an unreasonable risk. Even without assuming malice on the side of the vendor, this demonstrates an inherent weakness of the responsible disclosure process (understood as accepting arbitrary vendor-provided disclosure timelines): while some vendors are quite willing to give security issues top priority, and will actually work to get things done - others may exploit the rhetoric to mask staffing problems or the inability to drive engineering decisions effectively. Cheers, /mz ___ 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 Wed, Jan 20, 2010 at 10:25 AM, Dan Kaminsky d...@doxpara.com wrote: Seriously. I mean, just look at Linux, Firefox, and OpenOffice. Pristine code, not a single security vulnerability between them :) That's a red herring. His point was the public perception of the software company-- true or not-- would be hindered because Microsoft is all-encompassing. Compared to the world of open-source, the risk is distributed by the sheer virtue of software engineering being distributed amongst thousands of entities. This means that the vulnerabilities are spread across different parties, rather than having all vulnerabilities encompassed by a single party-- in this case, Microsoft. His argument was irrelevant to corporations vs. open-source being more vulnerable than one another-- it was simply a commentary on distributed risk in software engineering. -- Did you and them get your degree from the same university of trolls? I have mistaken nothing for nothing. Fuck 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/
