Introducing Windows Defender Application Guard for Microsoft Edge
blogs.windows.com
blogs.windows.com
(Disclosure: Microsoft is my employer.)
The idea sounds similar to Qubes OS, with the exception that it's transparent to the user and doesn't have to be configured by the end-user.
I presume this kills any of the offline-storage approaches?
But anyhow this is quite amazing idea, Microsoft really tries hard to improve Edge.
The reason they can overcome technical difficulty of something this cool is because they have very consistent and very limited underlying platform (they don't have to support macOS, Linux, etc). Imagine how hard it would be for Firefox and chrome to pull off something similar.
>I presume this kills any of the offline-storage approaches?
Not necessarily, it depends on how they did implement this.
(I may be wrong,please correct me)
I'm really hoping for the former, as it'll mean they finally might expose a KVM-esque API. That would mean a drastic change for virtualization dev on Windows.
This looks like a use of those containers for running edge processes.
So basically when you run this protected Edge session it starts the browser in a Hyper-V container, it has some read access to the host file system, registry, etc. but no write and when the session is closed everything else goes with it.
https://www.acsa-admin.org/2006/papers/epstein-paper.pdf
Vendors of separation kernels, with Green Hills in lead, started distributing MILS workstations with browser VM's and such in 2005:
http://www.ghs.com/news/20050419_secure_products.html
Tahoma started first browser-oriented OS running on Xen and Linux in 2006:
https://www.gribble.org/papers/gribble-Tahoma.pdf
Finally, OP Web Browser applied POLA and safe languages internally around 2008 with Chrome partly copying it (with less security for performance):
http://www.cse.psu.edu/~trj1/cse543-s15/docs/grier_sp08.pdf
So, high-assurance community has been on this with numerous projects and products released. Many had small, strong TCB's. The oldest had the color schemes and everything. QubesOS is the newcomer with less security than many forerunners but great usability & openness. Better than average Linux distro. Closest to prior designs with active community is genode.org.
This is pure speculation on my part; I have no evidence nor any investigation, deep or otherwise.
Haven't been introduced and haven't been found. It's both. Microsoft's SDL has dramatically reduced number of 0-days in their products. I speculate that eliminating many common vulnerability classes also eliminates a lot of the low-hanging fruit that's easiest to spot in the binaries by reverse engineers. They have potential to raise the security even higher if they apply MS Research's tools like VCC or Dafny. I don't even know what Edge is written in, though.
Cappsule (open-source for Linux), https://cappsule.github.io
virtualize any software on the fly (e.g. web browser,
office suite, media player) into lightweight VMs called
cappsules. Attacks are confined inside cappsules and
therefore don’t have any impact on the host OS.
Applications don’t need to be repackaged, and their usage
remain the same for the end user: it’s completely
transparent. Moreover, the OS doesn’t need to be
reinstalled nor modified.
Bromium and Microsoft partnered in 2015
.. extends VBS – isolating the execution of targeted
applications such as the browser, documents, executables,
downloads, attachments and media files .. to all
vulnerable applications on all Windows 7, 8 and 10
endpointsThen 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.
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.
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.
That's my theory anyway. They share source with some but highly selective with plenty restrictions.
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.
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.
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.
I also can't overemphasize having clear standards to evaluate against. Then, you can have it done in a jurisdiction with strong contract law where they legally have to check it against the evidence. Make sure they publish a statement to the effect of what criteria it met to what degree. Potential to use lawsuits against them.
OpenSSL is a good example of this, because even seasoned programmers trusted the code on the good name of the project and a few notable personalities. All the while told, "Don't write crypto code. It's too hard, let the experts handle it."
And look where that has gotten us. A million eyes all glazed over the same bug.
I'm unaware of concrete evidence that open sourcing code affects security outcomes either way. Do you have any examples?
An impossible standard, how do you purpose to measure that?
>And look where that has gotten us. A million eyes all glazed over the same bug.
How is a less eyes a solution to that problem?
Allow me this thought experiment: One person holds up a black box and asks you to stick your hand inside promising up and down that it is not full of venomous snakes, another person does the same with a transparent box. You are blind, but there are some well meaning (though not perfect) people in the room who don't want to see you hurt and they see no snakes in the clear box. What box do you choose?
Number of compromises for product/system X vs open alternatives. Number of published vulnerabilities. Time to patch them. Evaluation of binaries for common issues showing if even basic, due diligence was applied. Results of independent evaluations against meaningful criteria, such as QA methods used & results of them. There's quite a few ways to assess this.
"How is a less eyes a solution to that problem?"
How is no eyes looking at specific OSS a solution to the problem? Pointless questions not focusing on the issue.
"Allow me this thought experiment: One person holds up a black box and asks you to stick your hand "
Now, lets say the same thing happens FOSS-style. The box is clear but people dive in blindfolded without being asked. That's vast majority of FOSS with negligible security benefit. Next, someone looks at the box but has neither seen a snake nor knows which are venomous. This is people glancing at the code. Lets say they know 1 or 2 venomous snakes, ask they be removed, and dive into the others because they didn't know how to spot them. This is amateurs or pro's with little domain knowledge knocking out low-hanging fruit (err, snakes). Finally, let's say an expert on all poisonous snakes puts significant time inspecting the box to make sure no adults or even babies lurk in there. After they're gone, the expert inserts their hand with no damage unless a new type of snake was hidden in there.
I choose the box where an expert looked inside to remove as many dangers as possible. I don't care if it's open or closed for my baseline: just that it was vetted by reliable people with evidence it's the same box. Most proprietary and FOSS software doesn't meet this standard although it was mostly proprietary that reached highest level of proof. Took a lot of expensive experts years to do it is why. FOSS theoretically has an advantage due to free labor but they just don't do high-security. Hard to get them to use safer, systems languages and unit testing much less high-security methods.
So, there's your example. It withers away once the truth is once again demonstrated: it's the review(s), what was reviewed, and if you trust reviewer or review methods. OSS only helps in rare case that more pro's or experts are interested in doing that. It occasionally happens but too rare to be the rule for the baseline.
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.
>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.
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
""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.
CDCFKW.zip not saying anything.. just sayin :P
And indeed; very few companies spent as much money as Microsoft on their entire SDL. Sadly never had the chance to get a look into Google's kitchen but I'm hearing that they're great too.
They're also not dealing with the kind of backwards compatibility that Microsoft is dealing with which helps them out a lot too.
People interested in Microsoft Research's work on secure browsers should look at Gazelle browser and Xax plugin architecture:
https://www.microsoft.com/en-us/research/wp-content/uploads/...
https://www.microsoft.com/en-us/research/wp-content/uploads/...
It does sound like an interesting capability for private browsing, but existing mechanisms mostly cover that. Even if WDAG applied to private Windows, ordinary users aren't so likely to open private browser windows just to check a link from an email.
I expect that if you had a copy of Win10 Enterprise you could configure the feature yourself for added security in paranoid cases (e.g. journalist covering abusive regimes who might be targeted by state-level malware).
You should enable Ad/tracker-block by default and across the board.