Java was supposed to be sandboxed entirely with zero chance of malware getting to anything other than it's own litter tray. Look how that turned out when it was seen as all too hard and compromises were made.
The big problem with Java is that it requires quite a bit of C "glue" code to interface with the underlying operating system. The glue code necessary is often quite complex too, since it has to contend with issues such as the VM rearranging objects (thus glue need to "pin" the objects), garbage collection using a mark-and-sweep (thus the glue code need to make sure objects do not "dissapear" during the call), strange memory layout, multithreading/cpu cache issues etc, etc.
So while from the Java developer things may look simple, copious amount of complex glue code is need with all the traditional opportunities for security bugs.
There are probably more explanations than how the language runtime integrates with the OS, but the comparable .NET Framework seems to fare *a lot* better
Then there's the opposite that was born stupid, things like Active-X from MS that were such a stupid idea that a librarian (not a programmer) was telling me how stupid it was before launch.
ActiveX controls on the web was a stupid idea. Faced with the threat of Java applets, Microsoft decided to take a sound (and efficient) binary standard from the OS and put it on the web. The big problem with ActiveX is that from the OS perspective (at least until Windows 7) it is but binary code executing under the user account.
Imagine a system where you do not have sufficient control over what a process can do (because it is binary code executing directly against the OS), so instead you try to limit who can use what binary code - and under which circumstances. But once the code executes it acts as part of the host process. That actually works until some sneaks in malicious binary code, or - more likely - someone finds a memory corruption bug or finds a way to use the binary code in ways not intended by the developer.
That is putting a lot of trust in 3rd party developers, trusting that they do not have malicious intent and that they are actually competent and that proper quality assurance processes are in place. That turned out to be a stupid thing to trust (contrary to popular belief there has been precious few vulnerabilities in the ActiveX implementation itself - it was always the ActiveX controls -mostly 3rd party - that had vulnerabilities).
However, the idea behind whitelisting ActiveX controls was not new. It had been tried before (albeit not on the 'net), with similar results in terms of vulnerabilities, exploits and system compromises. To this day SUID/setuid is the most stupid intentional security weakness in the *nix security model, simply because - like with ActiveX - the permission structure is otherwise not capable of meeting simple, legitimate requirements.
Then things like allowing execution of arbitrary code in images, another case of MS fucking up in a truly astonishing way
I believe you may be confusing something here. When there is a vulnerability where a jpeg can "execute arbitrary code" it is *not* intentional. It is usually down to a memory corruption bug (such as buffer overflow), i.e. it is *unintentional*. I don't believe MS has made any image format with intentional capability to execute arbitrary code. If you have information to the contrary, then please cite source.
If you are insinuating that it is only MS who can make mistakes in image processing code, you should tread carefully. Compared to the typical open source libraries (libxml, libtiff, libpng et al) MS has had precious *few* vulnerabilities.
The answer as always is to learn from the lessons of the past instead of throwing together a pile of bits that look software shaped and rushing it out the door.
Yes. But if you want to learn the right lessons you must be careful to perform an unbiased analysis. Otherwise your results will have absolutely zero value towards avoiding similar situations in the future. Your petty attempts at laying this at the door of MS is an example of this. If - in your mind - the problem is simply MS, then you are overlooking the real problems. Ask yourself this: Why is it that it is only MS who has not had a *major* bug in their SSL implementation? (hint: MS SDL outlaws the use of the exact C library functions that were behind Heartbleed, so MS actually has a process in place where they analyze previous vulns and improves the guidelines for future development so that they can avoid *similar* mistakes).
