Weekly Microsoft Critical Security Issue

An anonymous reader sent in linkage to a zd story discussing the latest Windows Security Patches including an especially nice hole letting Java apps gain total control of your machine and assist you in reclaiming disk space by, say, reformating your drive.

Comments

jvm

[AbdullahHaydar]

which virtual machine is it that caused this? The one before or after Microsoft added their own extensions? (which caused the whole MS-Sun lawsuit)

I don't think we can be too critical, actually.

[caluml]

It hasn't been too nice for Open Source recently though has it?

Couple of remote roots in Samba, a local ptrace in the kernel and a few OpenSSL probs to get you on the system initially.

Re:I don't think we can be too critical, actually.

[the_pooh_experience]

It hasn't been too nice for Open Source recently though has it?

It is interesting you say this, and I think this is to blame for a good amount of FUD on both sides.

First off, anyone thinking there will make an uncrackable system is both naïve and asking for someone to break into their system. No one will make an unbreakable system (and plugged in), it is just that harder systems will take longer to break.

In this same vein, the nature of a piece of software's security can not be measured only in security updates or patches. You are right, OSS has had cracks recently, but the fact that you know about them and that (most) of them are fixed is reassuring. I would venture to say that something that didn't have patches or updates was simply not worth hacking, or not maintained (i.e. MS has not sent out patches/security updates for Win3.1, but does that mean there are no more problems with it?)

On the other hand, This believe must be mitigated by the understanding that more vulnerabilites announced are also not necessarily a good thing, and may reflect in shoddy programming.

This is the double edged sword that we must cut ourselves with. The real "tell" (I believe) is the level of sophistication in (most of) the vulnerabilities. Unfortunately, I know almost nothing, so I leave it up to others to tell me how bad they are. I guess it is a good thing I am not a sysadmin.

Hmm...

[Anonymous Coward]

Doesn't it seem just a little strange that the Java VM, which MS removed from XP until it was forced to reinclude it by court order (still under appeal, I believe), has a critical security hole found?

The timing seems a little too good to be true...

Re:But quickly fixed...

[ManUMan]

One can be excited when they patch things this quickly. My real concern is to whether we will see tons of patches for forthcoming software. That is, will all of the talk of more 'secure' computing be just talk.

I certainly agree that Win 2k, XP, etc. all seem to have more security bugs than you can shake a stick at. Given the problem, the question is can MS make any sort of headway? Can they actually offer a product that will really be stable and secure? My theory is that we will know a lot more about the answer to these questions in six months. If Win 2003 server has 18Mb of patches in the first 6 months then we will know the answer. Personally, I am hoping the start doing better.

Re:But quickly fixed...

[bittmann]

Yes, maybe, but...

Thanks to a long list of overlapping issues, this is going to cause my employer (and a vendor that shall remain nameless to protect the guilty) a bit of a headache--and I doubt that we're alone in the world on this one.

We are running a Digital Imaging (digital radiology) sytstem that has a web-based server for allowing physicians to review images and interp from "any PC". The viewer itself is Java based...no client required (ahem...vendor speak. Client is downloaded automatically, perhaps? Anyway...) The elimination of the need to manage/install/maintain a client on thousands of different machines was one of the biggest reasons that management chose this particular system/particular vendor.

Background:

Here's how the IT assessment of the product went...

Yay...Java! This will run on any PC! Well, not Mac or Linux, but since we aren't a Mac or Linux shop, this is acceptable (this should have been our first clue).

Well--make that "any PC running Internet Explorer". Perhaps it's something with a particular DOM. We can live with that. We're running IE on all of our machines, anyway.

OK--make that "any Windows PC running Internet Explorer, using Microsoft's Virtual Machine. Sun's won't work". WTF? I thought this was JAVA. Let me guess...this was written using MS Visual J++, right?? Anyway, according to our management (who is undoubtedly quoting straight from the vendor), "it's a lot faster this way."

Ummm--make that "any Windows PC running Internet Explorer, using one of a few versions of Microsoft's Virtual Machine...the most recent ones will *break* the app". Now, where did *that* come from? But sure enough, if an employee gets overly "helpful" and tries to update their system (we still have some 9x systems on the network, and the boss won't let me firewall the Windows Update site), the application breaks. So whatever the vendor did isn't entirely "legal"...the latest VMs "fix" an undocumented feature that they are depending on...

Final analysis: "This sucks. Either plan on installing their Honest-to-Pete MS-VC++ client on 1,000 PCs or pick another vendor."

So, yes, management went ahead and bought the package - warts, J++ and all - from the vendor for a goodly sum, over the objections of the IS review committee. Yes, we've fought with said vendor for the last few months, to no avail (yet). No, the vendor (until now) claims that there is no reason to update their code to be fully Java-as-in-Sun compliant (or even Java-as-in-current-Microsoft compliant, for that matter), and that we should basically stop whining and get over it. But perhaps, just perhaps, we can now point to this and say "Look. Your cusomers *are* at risk. We *must* upgrade our JVM...we have no choice. If your software won't run on the resulting platform then it's not performing as indicated, which frees us from the contract and any pending payments coming due. Hint Hint."

Well, I'm not holding my breath on the vendor updating their code. I am holding my breath about this cycle of Windows Update problems, however. I imagine that the trouble tickets are already starting to come in to our PC support area. "The Radiology viewer doesn't work," they say. "I can't do my job...fix it now!" they demand. Much work to uninstall the new VM. Much work to re-install an older version so they can "do their job". And much sweating while we hope to dodge the bullet of a malicious Java applet through a combination of virus detection software and dumb luck.

Sometimes, a blind patch via Windows Update isn't the best thing to do, unfortunately.

Am I blaming Microsoft for building unsafe Operating System software? Well, yes, but I'm also a realist--you can't expect perfection. But what I'm really blaming Microsoft for is their knowing and purposeful design and dissimenation of a Java VM and Java development environment that was built to be incompatible with Sun's Java. I'm also blaming the vendor for helping support Microsof

A bit of history and compiler theory....

[Ryosen]

Microsoft intentionally extended the core API by introducing additional instructions to access the underlying Win32 operating system. Had they done this by providing a separate API, there would not have been any problems.

Unfortunately, Microsoft chose to take a different approach and introduced new operators into the core byte-code interpreted by the Virtual Machine. As these additional instructions were only valid within Microsoft's version, users were effectively left with no choice but to use the exact VM for which the code was compiled. This decision by Microsoft to modify the base instruction set of the Java language made it impossible to port code from one platform to another, thereby ensuring that users would have to remain on the Windows platform. In fact, Java programs compiled for MS's VM would not even work on the same OS if another vendor's VM was used to run it. This is why some applets wouldn't work with the JVM shipped with Netscape (which was Sun's JVM).

The instruction set supported by a Java VM is determined and maintained by Sun. In order to implement your own VM, you must agree to a license with Sun stating that you will not modify the core instruction set. In adding direct support for OS access (such as formatting a hard drive), Microsoft violated this license agreement. Microsoft also added their own keywords to the core language (delegate and multicast) which further ensured incompatibility.

The Java byte code is a single byte in size and, as a result, the Java VM spec supports up to 256 op codes. Not all of them are used, however. Out of those potential 256 opcodes, only 200 valid operators are specified. Opcode 186 is not used, opcode 201 is used for debugging, and codes 254 and 255 are used for trapping and tracing. The remaining opcodes are reserved for future use. Clearly, if a compiler introduces new opcodes, the other compilers won't know about them and won't be able to run programs built with those opcodes. This is in direct violation of the VM specification and is exactly what Microsoft did. This was the basis for the Sun v. Microsoft lawsuit, for which Microsoft was found in willful violation.

So, it would seem as if Microsoft did intentionally break their own version of Java.

If you still do not understand how Microsoft did this on purpose, I suggest that you take a look at the Java Virtual Machine Specification, as well as a nice book on general compiler theory.