41–50 of 137 posts
This is the result of nearly a decade of work from MSFT, across the board. They built better tools, drilled security into every new hire all the way to the execs, made it a part of every engineering and product process imaginable. Happy that is finally being acknowledged on the outside.
Now I wish Adobe would do the same thing.
Earlier quoted context omitted.
> I know the saying many eyes make bugs shallow, but so does billions of dollars and years of concentrated effort. The saying holds. Billions of dollars buys many eyes.
That's not really how secure coding works at Microsoft though. There aren't more eyes on the code, just more developer training and more processes in place. (At least that was my experience working there from 2006 to 2009.)
It's actually this bit from farther down that surprised me the most: > 56 percent of exploits blocked in Q3 use Java vulnerabilities. So much for the idea of a managed language runtime being inherently more secure...
The JVM is good. The Java Applet Plugin, on the other hand, is a problem.
It's actually this bit from farther down that surprised me the most: > 56 percent of exploits blocked in Q3 use Java vulnerabilities. So much for the idea of a managed language runtime being inherently more secure...
The runtime isn't written in a managed language, and that's where most of the vulnerabilities happen, right? The holes aren't in application code, but in _running arbitrary code_, which the JVM fails to do safely. The surface area exposed is larger, because you're allowing the browser to download and run arbitrary programs, something you don't do with unmanaged languages very much. Edit: Also, just consider how much…
At least some of those Java vulnerabilities are logic errors in the sandboxing/securitymanager parts that are supposed to prevent applets from accessing privileged APIs, and those checks are usually implemented inside the actual java.* standard library classes, in the Java language.
It's actually this bit from farther down that surprised me the most: > 56 percent of exploits blocked in Q3 use Java vulnerabilities. So much for the idea of a managed language runtime being inherently more secure...
The problem mostly isn't the runtime itself, but instead the various 3rd party modules (all of which are written in late-90's-era C/C++) that get hooked up to the JVM. For instance, the Quicktime API for Java exposed scalar integers, intended to be "opaque", but in fact raw memory locations. The JVM is good. The Java Applet Plugin, on the other hand, is a problem.
And contrast with alternative affirmative/MAC-based sandboxing schemes like Chrome's NaCl, or OS-level stuff using SELinux/AppArmor. These don't require a managed runtime at all, and yet appear ("appear" being a critical point of courses) to solve this problem in a more robust way.
Haha. Great to see iTunes and QuickTime (Windows versions, probably?) on the list... Apple should really either update them (I'm not sure iTunes 11 will be released for windows too) , or just abandon them (and ask customers to use iCloud for backup). A few days ago I opened a .mov on a Windows machine with QuickTime - it was horrible. I can't imagine how dreadful iTunes probably is. No wonder all PC guys hate iTunes.…
I hate iTunes on every platform. It's bloated; it tries to do too many things and it does them all wrong. Just as an example, searching for anything with iTunes is a horrible experience, particularly when compared with searching the 'net with any of the top search engines. Book, app and media management are terrible. Cross-computer management of the same is terrible. Backing-up your iPhone, if you are not careful, ca…
The sheer number of bugs that crapware has is unbelievable. And don't get me started on Music.app on iPad (iOS 5 and 6), or the dreadful state of "Shared Media" in iPhone and iPad's Music apps (stream from a computer).
God I hate them. If I ever switch from iOS/Mac, iTunes/Music.app are to blame.
Earlier quoted context omitted.
The problem mostly isn't the runtime itself, but instead the various 3rd party modules (all of which are written in late-90's-era C/C++) that get hooked up to the JVM. For instance, the Quicktime API for Java exposed scalar integers, intended to be "opaque", but in fact raw memory locations. The JVM is good. The Java Applet Plugin, on the other hand, is a problem.
Well, sure. But I think that's maybe missing my point -- a managed runtime needs "holes" in it to do its job, which exposes the security problems of the rest of the system via inevitably leaky abstractions. The point was that the managed runtime does nothing to address this, it has to drill down to a C API at some point (or deeper, consider a similar hole in a shader compiler or video codec accelerator). And contrast…
I'm not sure we really know how to secure a desktop application / fat client platform yet.