Slashdot Mirror

While saying "Apple isn't blocking Sun/Oracle's ability to ship Java for the OS X platform" sounds wonderful, it neglects reality.

Your implication with this statement is that Apple is actually blocking Java on OS X, but that's completely untrue. You act as if it's Apple's obligation to be providing a JVM. It's none of Apple's problem that Sun never did. Apple was doing them a favor by providing their own JVM all these years. Keeping it updated wouldn't be any more difficult than any other third-party updater. Right now, Mac apps already use their own updaters, often through a framework called Sparkle.

Your dismissal of these points as "a good Apple PR position" doesn't change the fact that Apple has never stopped anyone from providing a JVM. In fact, here's a third-party port of BSD Java for the Mac.

If Oracle wants Java on OS X, they can do it themselves like they already do for Windows. Absolutely nothing is stopping them.

Why is it that Apple is expected to be the only platform vendor that has to maintain their own version of the JVM for free?

Because it's their loss if they don't.
Windows has a major market already in business desktops, their JVM can't be dropped. Linux has a major market in the server business, their JVM can't be dropped. Apple has nothing to convince Oracle to support their JVM.

I don't understand why on Earth any Java dev would want to be stuck indefinitely with Apple's outdated implementation that by definition would never be a major priority rather then get a version from the main organization behind it.

Because the main organization doesn't have such version, and probably won't in the future even with this announcement. What's Oracle business case for supporting it?

If we had a fully open GPL edition of the JVM that was best of class like we should have gotten years ago, this never would have been an issue in the first place.

OpenJDK has been GPL for two years now. And there is an OSS BSD port of the JVM that runs on the Mac. The problem is that converting it to use the Mac's libraries instead if X11 and so it's hard work.

If someone is causing trouble, it's Apple for not releasing their JVM as OSS.

Build a Java VM in 8 months? That's not going to be a very good JVM.

Why? It took less time than that for a single developer to release a 1.6 JDK when Apple was dragging their feet on it.

I'm confident that alternative JVM implementations will fill the void: If you remember, Apple was slow with Java 1.6 and even then did not provide a 32-bit version for some time afterward, but third parties have already stepped in even on that relatively limited niche. What concerns me though is that third party ports may lack some of the nice OS X integration that Apple has implemented, allowing various UI tweaks to feel like a native app, or that there will be multiple ports with different integration interfaces, and Java apps will become fragmented or avoid using the features due to inconsistent support.

Anyway, also keep in mind this could be due to expiring Sun contracts, or the new Oracle owners might want to supply the JVM themselves instead of Apple, although I admit the obvious explanation is simply that Apple is making a power play. But Apple hasn't always done the best job with updating their JVM, so having a version from a cross-platform vendor may put more emphasis on synchronization, standardization, and portability, which in the end could actually make life easier for your business apps.

So this security problem did not exist? Yes, it's a problem in Java, but Java is part of the default MacOSX installation, and Apple only fixed the problems months later.

...but I didn't have a mac, so I had to use a vm with an unpatched linux (ubuntu 8.10 actually). I tried to convince a guy with a mac in the audience to go to my exploit url, but he was not willing... One cool thing of this exploit is that it is pure java, so the same exploit can work on linux, mac and windows.

Here is a writeup on the vulnerability: http://blog.cr0.org/2009/05/write-once-own-everyone.html

And here is a proof-of-concept exploit: http://landonf.bikemonkey.org/code/macosx/CVE-2008-5353.20090519.html

You can decompile it to see what's going on exactly.

Enjoy.

Normally I absolutely agree. Most vulnerabilities are overhyped. Not this one though. Read this article and click the link to a page that runs /usr/bin/say on your unpatched machine.
http://landonf.bikemonkey.org/code/macosx/CVE-2008-5353.20090519.html

Security patches are good. For instance, java has a remote execution issue that is 5 month old. See this blog

In that page, you have a link [BEWARE, DON'T CLICK], which will execute arbitrary code (the guy says it is harmless, I believe him, but you don't have to), on your fully-patched, up-to-date OSX. I checked it, it works.

So, well, I, for one, guess that a high bug fix list is a good thing. I wish that Apple fix list count was one higher.

Security patches are good. For instance, java has a remote execution issue that is 5 month old. See this blog

In that page, you have a link [BEWARE, DON'T CLICK], which will execute arbitrary code (the guy says it is harmless, I believe him, but you don't have to), on your fully-patched, up-to-date OSX. I checked it, it works.

So, well, I, for one, guess that a high bug fix list is a good thing. I wish that Apple fix list count was one higher.

The Mac version of Chrome requires Intel CPU and Mac OS X 10.5.6 or later. So the (vast number?) of Mac users that are either still using a PowerPC-based or Tiger will have to sit this one out. With luck and perhaps some prodding, Google will produce a universal binary version that runs on 10.4.x as well. The Leopard dependency might indicate a requirement for Java 1.6, which is not supported in Tiger, unless you have an Intel mac.

It looks like OpenJDK now runs on MacOSX:

http://landonf.bikemonkey.org/static/soylatte/

No patch is currently available -- a fully patched 10.5.7 system remains vulnerable. See also http://landonf.bikemonkey.org/code/macosx/CVE-2008-5353.20090519.html

In addition to disabling Java support, Safari's 'Open "safe" files after downloading' must also be disabled to prevent websites from automatically loading a Java WebStart application via a JNLP file.

I've also posted a demonstration of the vulnerability at http://landonf.bikemonkey.org/code/macosx/CVE-2008-5353.20090519.html

First, you're just limited to 32-bit jdk 1.6. You just can't used 64-bit jdk 1.6.

Second, someone has released a different jdk 1.6 for the mac, which is now part of openjdk:
http://landonf.bikemonkey.org/static/soylatte/

Looks like that effort has been officially merged into the OpenJDK project, and OpenJDK 7 is already running:

http://landonf.bikemonkey.org/code/java/OpenJDK_7_Binaries.20080820.html

I'm rather surprised to hear that Apple even releases a version of Java. The Apple Tradition is to give you one way to do something and that's it. I can see Apple looking at Java and asking, "what does this have to do with us?" It's not a key part of their system and in fact probably competes to a certain degree with their official Jobs-sanctioned One True Development Platform.

And another thing: What's preventing Sun (or an interested third party, now that Java is open source) from releasing an up-to-date version of Java on Mac?

I'm not sure. There was talk of porting the OpenBSD JDK to Apple but I'm not sure how far it went: http://landonf.bikemonkey.org/code/macosx/MacOS_Java_16_Developer_Preview_1.20071120.html

I suspect Sun was more than happy to let Apple take ownership (Sun isn't doing too well, financially speaking) and Apple was all too happy retaining full control of how Java behaved on their platform (Apple loves being in control ).

Personally I wouldn't trust Apple to keep on maintaining the port. Most 3rd-party JDK providers inevitably are busy doing something else and let the port fall behind. I almost wish Apple would pay Sun money to maintain the port. It would be a win-win for both parties.

Have a soy latte instead.

Whats the state of navigation for linux in car systems? It'd be fun to homebrew one, but without decent navigation it's not a whole lot of use.

I'm sure i should have some BSOD joke in here too, but i haven't had my coffee yet

Navigation is a hard problem, primarily due to a lack of data. There are free sources (as in public domain) of street line data for many countries, however you need topological network data to accurately route a car -- street intersections, one-way streets, weighting of streets according to real-world local conditions, etc.

The US Census releases the TIGER data, and OpenStreetMaps builds on that (and other) data with a public domain wiki-style site, but neither sources have sufficient topological data to route autos.

There are two primary providers of topological map data -- you'll see their logos at the bottom of most maps, including Google Maps: NavTeq and TeleAtlas. For a brief introduction to the scale of the problem, I'd actually recommend watching TeleAtlas's marketing video on their production process

I'd love to see furtherance of open topographical data -- data about the communities around us is useful for more than just routing automobiles. One very interesting development is Google StreetView. In taking these photographs, Google has removed the need to actually drive the routes to gather, correct, or refine data -- they can collect the photographs en-masse, allowing more specialized analysis to be done offline -- anyone, anywhere, can determine whether a street is one-way, where the freeway on-ramp is, etc.

I should also mention that OpenStreetMaps uses a share-alike creative-commons license. The definition of an "aggregate work" of data is very fluid -- I can not use OSM data, since I can't combine it with data available under different licensing -- even publicly available municipal data that simply can't be re-licensed CC Share-Alike.

Where were you past 3-4 months? :)

Landon Fuller and a team made Java 6 running under OS X X11 (and command line of course)

http://landonf.bikemonkey.org/static/soylatte/

It is said to have great performance too.

The real issue is, how to make that gigantic thing available to PPC G5 and G4/G3 (if they accept perf. penalty) processors under OS X. X11 could be OK too. The Java 6 release(!) from Apple is Intel 64bit _only_. We can't ask Apple as they even abandoned Intel 32bit users (on that release) so there should be some team, likely from IBM needs to step in. They shipped Java 6 for Linux PPC/PPC64 ages ago. They should step in and save/support their CPU customers, especially G5. While people buy G5 workstations/servers, they also bought IBM CPUs.

You don't even have to recompile dtrace, there's a kernel extension that patches around Apple's code. http://landonf.bikemonkey.org/code/macosx/Leopard_PT_DENY_ATTACH.20080122.html

As quickly as the issue is reported, a hack comes out to resolve it. Gotta love how quickly the community can respond to these things.

Off-topic we go.

Here's an implementation of a double-blind time-limited drop-box via DNS:
http://landonf.bikemonkey.org/code/security/DNS_Dead_Drop.20060128201048.26517.luxo.html

It's not undetectable -- the RD bit is not widely used -- but it's likely under the radar, especially if you use a DNS server located in another, non-cooperative country. Does tor support routing DNS queries out the network? That would be somewhat resilient to detection.

One nice thing about the methodology is that when posting the message, only '1' bits are observable. '0' bits are never sent, so try doing analysis on: 11111111111...

Retrieving the message, the 1s and 0s are (obviously) available, but your message is encrypted, right?

In the meantime, Landon Fuller is doing an admirable, if duplicated, job of single-handledly porting Java 6 to OS X based on the efforts for BSD.

Java 6 was released more than 12 months ago for other platforms. "fake" and real Steve may dismiss Java as irrelevant but the truth is Apple have dropped the ball.

I develop Swing applications and it's frustrating that we can't use new features of Java 6 because we have to support OS X's legacy Java 5 implementation.

The majority market share is still Windows. While Apple lags with Java it's hurting Linux AND OS X. Much as Java-haters on this site would like it to disappear, Swing is still an option for cross OS deployments in the enterprise, offering a rich client alternative to web-browser environments. At times the option of supporting an application for Win32, Linux and OS X with native toolkits is not viable. More likely it's mandate Windows-only or use Java.

Further rumours of running Windows apps natively in OS X, are nothing new. A decade ago, the idea was touted as Red Box.

Many posters have argued that for Apple to actively support other platforms natively such as Win32, .NET, KDE, GTK and Java are counter-productive in terms of promoting their own native Cocoa and iApps. However providing OS level hooks to run .Net/Windows applications through mono/wine would allow 3rd party volunteers to complete the efforts. [Off-topic]Similarly, Apple mightn't be an active participant in the virtualization area such as porting Xen but providing implicit support in XNU wouldn't hurt either[/Off-topic].

I have another wild theory: It might actually exist and be a, currently, hidden Apple internal subsystem for running cross-platform applications in XCode. Since the NeXT days, there's been a Cocoa subsystem for Windows which facilitates Apple building iSuite apps for Vista. The missing piece? Click Run in XCode and an embedded Wine-subsystem will launch enough of Windows to show you, with high fidelity, how the application will behave under Vista/XP.

That scenario would save Apple a lot of time in terms of testing their Windows applications. If they wanted to re-launch Cocoa as a cross-platform deployment platform makes more sense, to me at least, than the proposal that Apple will endorse running natively the Windows version of Photoshop et alia.

From Anatomy of the Runtime MoAB Patches

------

01:04 Tue, 09 Jan 2007 PST -0800
Anatomy of the Runtime MoAB Patches

Introduction

For the past few days I've been releasing patches for software vulnerabilities in an assortment of Mac OS software. This project was intended to be a technical one, and I've never sat down to explain, in clear terms, how the patches work, what Application Enhancer is, or what the potential risks are in running these patches. I'm also not the first one (not by a long shot) to think of implementing third party patches for unpatched software vulnerabilities, either, and I'd like to discuss those efforts.

Here goes ...

Third Party Patches, Past and Present

Generally speaking, a software vulnerability is usually announced in coordination with a vendor-supplied software update. However, there are cases when a vendor patch is not available for a critical software vulnerability, leaving the user with limited options. Relatively recently, the idea of a "third party patch" has emerged; when a vendor patch is not available, a third party can reverse engineer the software in question and produce a temporary bug fix.

This technique has previously been used for both unpatched Windows and Mac OS X vulnerabilities. In 2006, Alexander Sotirov presented "Hotpatching and the Rise of Third-Party Patches" at the Las Vegas Black Hat conference, and is responsible for implementing two patches for unfixed Internet Explorer vulnerabilities. ZERT (Zero-day Emergency Response Team), who is composed of an impressive array of individuals, "work(s) together as a team to release a non-vendor patch when a so-called '0day' (zero-day) exploit appears in the open which poses a serious risk to the public, to the infrastructure of the Internet or both." On the Macintosh, Unsanity released Paranoid Android, a run-time patch for a critical vulnerability in Mac OS X's document handling. I believe the award for the first third party Windows patch for an unfixed vulnerability goes to Ilfak Guilfanov's December 2005 WMF patch. Guilfanov is the author of the excellent IDA Pro disassembler and debugger.

Risks and Benefits of Third Party Patches

A vendor-supplied update is always preferable to a third party patch. Third party patches are created by reverse engineering the vulnerable code, and are subject to limited testing and potential implementation deficiencies -- like the author of the vulnerable software, patch implementors are human, too. It is always possible that a bug in the patch could result in instability, or potentially expose a new exploit scenario.

On the other hand, a third party patch can provide protection against a critical vulnerability before the vendor is able to implement, test, and release a fix. The decision to use a third party patch should be made after a careful assessment of the vulnerability's risks and your own requirements -- it's never unreasonable to wait for an officially provided vendor fix.

Patching (more) Safely with Application Enhancer

The patches we've provided have all been implemented using Unsanity's Application Enhancer, and are "run-time patches" -- the patches insert themselves into applications at runtime, find the vulnerable code, and apply a band-aid. Nearly all of the patches released so far work by wrapping the vulnerable code and providing additional data validation, rejecting data that would otherwise cause the vulnerable code to malfunction (and thus allow the exploit to succeed). There are other options for implementing run-time patches on Mac OS X, including the open source mach_star -- I've previously used mach_star to implement runtime security patches for software on my own Mac. However, for the purposes of providing these fixes, I decided upon Application Enhancer.

Application Enhancer provides a nice, easy to use GUI for installing Applicati

Rather than just tell people not to use APE, Landon Fuller (who reported this bug on his blog), should have written an APE SHell Investigative Tool to help people find and fix this error.

Technology needs more catchy acronyms

Uh...then look at the source code yourself.

Nothing is hidden, and Landon isn't trying to hide anything that's being done.

Also, these fixes are runtime fixes via APE modules. They only place they're "installed" is into APE, so they can all be easily removed/disabled at will (as can APE itself). There is nothing wrong with the principle of runtime patching, and this is really a technical exercise more than anything. But again, the code is all right there, and you can see exactly what is being done.

I tracked down the issue and created a runtime fix using Unsanity's Application Enhancer. The overflow is in the QuickTime Streaming component's INet_ParseURLServer() function -- the fix patches that function and pre-validates the URL before passing it off to the real function implementation. If the URL is too long, the patch replaces the Evil URL with a benign, but invalid one, and then calls the original function.

It's worth noting that disabling RTSP, as noted elsewhere, is not sufficient -- there are other vulnerable entry-points to INet_ParseURLServer(), as it is used for generic URL parsing.

More information is available here:

http://www.unsanity.org/archives/mac_os_x/the_mont h_of_trolly_trolls_and.php

and the patch (with source!) can be downloaded here:

http://landonf.bikemonkey.org/code/macosx

You can test the fix (make sure to log out and log back in after installing APE!) in Safari (or Firefox) by visiting this URL:

http://landonf.bikemonkey.org/static/rtsp_crash.ht ml

If you're using Safari, QuickTime should display a "bad address" error once the patch is installed. If the patch isn't installed, Safari will crash.

I tracked down the issue and created a runtime fix using Unsanity's Application Enhancer. The overflow is in the QuickTime Streaming component's INet_ParseURLServer() function -- the fix patches that function and pre-validates the URL before passing it off to the real function implementation. If the URL is too long, the patch replaces the Evil URL with a benign, but invalid one, and then calls the original function.

It's worth noting that disabling RTSP, as noted elsewhere, is not sufficient -- there are other vulnerable entry-points to INet_ParseURLServer(), as it is used for generic URL parsing.

More information is available here:

http://www.unsanity.org/archives/mac_os_x/the_mont h_of_trolly_trolls_and.php

and the patch (with source!) can be downloaded here:

http://landonf.bikemonkey.org/code/macosx

You can test the fix (make sure to log out and log back in after installing APE!) in Safari (or Firefox) by visiting this URL:

http://landonf.bikemonkey.org/static/rtsp_crash.ht ml

If you're using Safari, QuickTime should display a "bad address" error once the patch is installed. If the patch isn't installed, Safari will crash.