13 ms·

"We’re determined to make Microsoft Edge the safest and most secure browser." Then open source the whole thing, not just little parts of it. It has the lowest

"We’re determined to make Microsoft Edge the safest and most secure browser." Then open source the whole thing, not just little parts of it. It has the lowest number of vulnerabilities in the National Vulnerability Database because it has the least number of eyes able to look for them.

pjmlp 10y ago
Yes, because it has helped OpenSSL a lot.
- michaelbuckbee 10y ago
  The point isn't that every open source app is awesome, it is that now you KNOW. You're directing snark towards OpenSSL presumably because you think it's a poorly coded. If it was closed source you might not even be aware of the issues and there certainly wouldn't be the open source efforts to code alternatives.
  - nickpsecurity 10y ago
    If it was closed-source, we would assume it had lots of issues until reviewed by a qualified, third party that we trust saying otherwise who also gives us signed hash for binary that was reviewed. The way it's been done in proprietary evaluations a long time. It would be done more if companies were actually interested in a real evaluation instead of a stamp that knocks out their liability. ;) Under DOD's TCSEC criteria, the high-assurance systems (A1-class) also had to be delivered in source form to paying customers with evaluation evidence. They can check hashes/signatures, check the evaluation evidence themselves, and build it on site. So, vendors got paid large sums of money to develop the products, independent evaluation ensured you got some pentesting, and you could inspect the source yourself. My modification to the scheme involved evaluators with hacking background in mutually-suspicious countries working side-by-side with developers every step of the way. Traditional open-source development is weak against all of these given there's usually a lack of qualified expertise or just people willing to dig into it. Just open-sourcing something gets people almost nothing in security. Has to be reviewed.
    - nkassis 10y ago
      In the case of edge, Microsoft could do both. Not sure where the drawback would be.
      - nickpsecurity 10y ago
        I think the main thing is that Microsoft makes billions from what lock-in remains in their tech. They are probably very afraid that open-source would've made things like OpenOffice happen for all their locked-in tech at great development speed and compatibility. Plus on better platforms that Microsoft doesn't sell. Maybe even ReactOS greatly accelerated by the availability of source. ;) That's my theory anyway. They share source with some but highly selective with plenty restrictions.
    - makomk 10y ago
      Some of the recent proposed international trade treaties would forbid governments from requiring companies to supply source code for their software, if I recall correctly.
      - nickpsecurity 10y ago
        No doubt inspired by bottom line and SIGINT concerns. In that case, it can be voluntary as a differentiator.
  - nneonneo 10y ago
    What matters most is the amount of security effort paid to the project, not whether it is open- or closed-source. Commercial decompilers, reverse-engineering tools and automated bug finders have come a long way - a determined reverser can find bugs in closed-source code almost as easily as in open-source code. But, both kinds of bug finding take time and loads of manual effort (despite good tools), and will often only happen with appropriate incentives. This is where closed-source has a major advantage: companies put up money (in the form of bug bounties) to counteract the bug prices that a researcher could obtain on the black market. This incentivizes "good" researchers to spend time on their products. Open-source projects, even highly-successful ones, rarely have enough funding to run good bug bounty programs. Consequently, good guys can't pay the bills finding bugs in open source, whereas bad guys get huge payoffs for finding and exploiting bugs (think the NSA, criminal groups, malicious states, etc.). As the adage goes, enough eyeballs render all bugs shallow. But, in this day and age, that applies both to open- and to closed-source code.
- nkassis 10y ago
  Not sure what you mean, it has benefited from security researchers looking at the code base. They haven't found everything but they found many things.
  - nickpsecurity 10y ago
    He means the quality is so bad that users of it could get owned by full, remote execution on a regular basis. That some people saw some flaws didn't mean anything. There were some alternatives, including commercial, where people put extra effort into checking how crypto interfaced or the quality of the code. Some even used static analysis to find common flaws. As I say, the difference in 0-days between them and OpenSSL is the effort that was put into the quality rather than how open they are. A closed development with good effort is more trustworthy than an open one with low effort or review. One exception being subversion where open-source can spot most idiotic backdoors. Less likely to catch good, obfuscated ones. From there, an open development with strong effort and review is more trustworthy than a similar, close one. Amount of effort and quality of review are only consistent indicators.
    - cmdrfred 10y ago
      >A closed development with good effort is more trustworthy than an open one with low effort or review. Good code is better than bad code obviously, but how do you know what you have if you can't see the source? It's Schrodinger's code, you don't know it's bad until it's too late.
      - nickpsecurity 10y ago
        Independent review of source with published hash for binary or analysis of assembly to compare it to baseline. Many problems that due diligence avoids can be detected at ASM level. You'd know they were at least doing that.
        cmdrfred 10y ago
        How do you pay for the audits without a conflict of interest? Unless it is crowdfunded in some way, the auditors would have incentives to not find anything.
tptacek 10y ago
It's been a little while since I was close to Microsoft (they were a client for a bit at Matasano), but: those people spend more on software security for WINMINE.EXE than a lot of startups do for their whole stack. Would their software be safer if it was open source? Probably. Open code is rarely a loss for security. But it's not easy to say how much safer. Probably less than you think.
- nickpsecurity 10y ago
  I recall the Windows source leaked a long time ago. One programmer wrote an article on it saying it was actually good code. The problem areas seem to be little hacks they had littered everywhere to keep 3rd party hardware or software from breaking. My bookmark leads to a missing article that's not in Wayback Machine. Do you have a substitute link to a review by a qualified person who got to look at the source? I'd be interested in that.
  - ksk 10y ago
    Yes, it leaked during the Win2K release cycle I believe. And you're probably thinking about the kuro5hin website, where someone claimed to have analyzed it. (http://webcache.googleusercontent.com/search?q=cache:3BlVJSk8XV4J:www.theinquirer.net/inquirer/news/1030335/leaked-windows-2000-source-code-analysed+&cd=7&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:3BlVJSk...) >One programmer wrote an article on it saying it was actually good code. "one programmer" commenting about 30+ million lines of code. Yeah. uh-huh. Anyway, you can still find the kernel's source if you care to dig around. Its the Windows Research Kernel but it's mostly unchanged from the commercial codebase. >The problem areas seem to be little hacks they had littered everywhere to keep 3rd party hardware or software from breaking. Those are mostly relegated to the compatibility shim layer. You can turn it off, in any case.
    - nickpsecurity 10y ago
      "Yes, it leaked during the Win2K release cycle I believe. And you're probably thinking about the kuro5hin website, where someone claimed to have analyzed it. " Yeah, my inability to evaluate the skill level or character of source was main drawback of claim. I gave a little credence to it because I knew that they were ramping up QA due to image problems and potential lost sales. Steve Lipner... who did high-assurance security with legendary Paul Karger... came in to turn it around with the SDL. Massive investment in professional programmers to find quality issues across the lifecycle implies it would have fewer issues than average software. https://msdn.microsoft.com/en-us/library/ms995349.aspx https://msdn.microsoft.com/en-us/library/ms995349.aspx ""one programmer" commenting about 30+ million lines of code. Yeah. uh-huh." You can tell a lot by glancing at random samples while digging into a bit fewer. Good, well-commented code with various security checks stands out for people that spend years looking at the opposite. All such a review could say, though, was that people were putting in effort. Actual security would need thorough review. "Anyway, you can still find the kernel's source if you care to dig around. Its the Windows Research Kernel but it's mostly unchanged from the commercial codebase." Will do. Appreciate the tip.
imglorp 10y ago
It's also still low adoption, so it's not a priority target for the bad guys or the researchers. This is why comparing CVE counts doesn't mean much.

pjmlp 10y ago

Yes, because it has helped OpenSSL a lot.

michaelbuckbee 10y ago
The point isn't that every open source app is awesome, it is that now you KNOW. You're directing snark towards OpenSSL presumably because you think it's a poorly coded. If it was closed source you might not even be aware of the issues and there certainly wouldn't be the open source efforts to code alternatives.
- nickpsecurity 10y ago
  If it was closed-source, we would assume it had lots of issues until reviewed by a qualified, third party that we trust saying otherwise who also gives us signed hash for binary that was reviewed. The way it's been done in proprietary evaluations a long time. It would be done more if companies were actually interested in a real evaluation instead of a stamp that knocks out their liability. ;) Under DOD's TCSEC criteria, the high-assurance systems (A1-class) also had to be delivered in source form to paying customers with evaluation evidence. They can check hashes/signatures, check the evaluation evidence themselves, and build it on site. So, vendors got paid large sums of money to develop the products, independent evaluation ensured you got some pentesting, and you could inspect the source yourself. My modification to the scheme involved evaluators with hacking background in mutually-suspicious countries working side-by-side with developers every step of the way. Traditional open-source development is weak against all of these given there's usually a lack of qualified expertise or just people willing to dig into it. Just open-sourcing something gets people almost nothing in security. Has to be reviewed.
  - nkassis 10y ago
    In the case of edge, Microsoft could do both. Not sure where the drawback would be.
    - nickpsecurity 10y ago
      I think the main thing is that Microsoft makes billions from what lock-in remains in their tech. They are probably very afraid that open-source would've made things like OpenOffice happen for all their locked-in tech at great development speed and compatibility. Plus on better platforms that Microsoft doesn't sell. Maybe even ReactOS greatly accelerated by the availability of source. ;) That's my theory anyway. They share source with some but highly selective with plenty restrictions.
  - makomk 10y ago
    Some of the recent proposed international trade treaties would forbid governments from requiring companies to supply source code for their software, if I recall correctly.
    - nickpsecurity 10y ago
      No doubt inspired by bottom line and SIGINT concerns. In that case, it can be voluntary as a differentiator.
- nneonneo 10y ago
  What matters most is the amount of security effort paid to the project, not whether it is open- or closed-source. Commercial decompilers, reverse-engineering tools and automated bug finders have come a long way - a determined reverser can find bugs in closed-source code almost as easily as in open-source code. But, both kinds of bug finding take time and loads of manual effort (despite good tools), and will often only happen with appropriate incentives. This is where closed-source has a major advantage: companies put up money (in the form of bug bounties) to counteract the bug prices that a researcher could obtain on the black market. This incentivizes "good" researchers to spend time on their products. Open-source projects, even highly-successful ones, rarely have enough funding to run good bug bounty programs. Consequently, good guys can't pay the bills finding bugs in open source, whereas bad guys get huge payoffs for finding and exploiting bugs (think the NSA, criminal groups, malicious states, etc.). As the adage goes, enough eyeballs render all bugs shallow. But, in this day and age, that applies both to open- and to closed-source code.
nkassis 10y ago
Not sure what you mean, it has benefited from security researchers looking at the code base. They haven't found everything but they found many things.
- nickpsecurity 10y ago
  He means the quality is so bad that users of it could get owned by full, remote execution on a regular basis. That some people saw some flaws didn't mean anything. There were some alternatives, including commercial, where people put extra effort into checking how crypto interfaced or the quality of the code. Some even used static analysis to find common flaws. As I say, the difference in 0-days between them and OpenSSL is the effort that was put into the quality rather than how open they are. A closed development with good effort is more trustworthy than an open one with low effort or review. One exception being subversion where open-source can spot most idiotic backdoors. Less likely to catch good, obfuscated ones. From there, an open development with strong effort and review is more trustworthy than a similar, close one. Amount of effort and quality of review are only consistent indicators.
  - cmdrfred 10y ago
    >A closed development with good effort is more trustworthy than an open one with low effort or review. Good code is better than bad code obviously, but how do you know what you have if you can't see the source? It's Schrodinger's code, you don't know it's bad until it's too late.
    - nickpsecurity 10y ago
      Independent review of source with published hash for binary or analysis of assembly to compare it to baseline. Many problems that due diligence avoids can be detected at ASM level. You'd know they were at least doing that.
      - cmdrfred 10y ago
        How do you pay for the audits without a conflict of interest? Unless it is crowdfunded in some way, the auditors would have incentives to not find anything.

tptacek 10y ago

It's been a little while since I was close to Microsoft (they were a client for a bit at Matasano), but: those people spend more on software security for WINMINE.EXE than a lot of startups do for their whole stack. Would their software be safer if it was open source? Probably. Open code is rarely a loss for security. But it's not easy to say how much safer. Probably less than you think.

nickpsecurity 10y ago
I recall the Windows source leaked a long time ago. One programmer wrote an article on it saying it was actually good code. The problem areas seem to be little hacks they had littered everywhere to keep 3rd party hardware or software from breaking. My bookmark leads to a missing article that's not in Wayback Machine. Do you have a substitute link to a review by a qualified person who got to look at the source? I'd be interested in that.
- ksk 10y ago
  Yes, it leaked during the Win2K release cycle I believe. And you're probably thinking about the kuro5hin website, where someone claimed to have analyzed it. (http://webcache.googleusercontent.com/search?q=cache:3BlVJSk8XV4J:www.theinquirer.net/inquirer/news/1030335/leaked-windows-2000-source-code-analysed+&cd=7&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:3BlVJSk...) >One programmer wrote an article on it saying it was actually good code. "one programmer" commenting about 30+ million lines of code. Yeah. uh-huh. Anyway, you can still find the kernel's source if you care to dig around. Its the Windows Research Kernel but it's mostly unchanged from the commercial codebase. >The problem areas seem to be little hacks they had littered everywhere to keep 3rd party hardware or software from breaking. Those are mostly relegated to the compatibility shim layer. You can turn it off, in any case.
  - nickpsecurity 10y ago
    "Yes, it leaked during the Win2K release cycle I believe. And you're probably thinking about the kuro5hin website, where someone claimed to have analyzed it. " Yeah, my inability to evaluate the skill level or character of source was main drawback of claim. I gave a little credence to it because I knew that they were ramping up QA due to image problems and potential lost sales. Steve Lipner... who did high-assurance security with legendary Paul Karger... came in to turn it around with the SDL. Massive investment in professional programmers to find quality issues across the lifecycle implies it would have fewer issues than average software. https://msdn.microsoft.com/en-us/library/ms995349.aspx https://msdn.microsoft.com/en-us/library/ms995349.aspx ""one programmer" commenting about 30+ million lines of code. Yeah. uh-huh." You can tell a lot by glancing at random samples while digging into a bit fewer. Good, well-commented code with various security checks stands out for people that spend years looking at the opposite. All such a review could say, though, was that people were putting in effort. Actual security would need thorough review. "Anyway, you can still find the kernel's source if you care to dig around. Its the Windows Research Kernel but it's mostly unchanged from the commercial codebase." Will do. Appreciate the tip.

imglorp 10y ago

It's also still low adoption, so it's not a priority target for the bad guys or the researchers. This is why comparing CVE counts doesn't mean much.