This bug reaches the severity threshold where ideally I wouldn't talk about it until a fix has been issued, but as the Facebook relationship status would put it: It's complicated. It doesn't qualify for ZDI because I already notified Sun by myself in 2008 about various vulnerabilities, first via their bug tracking (I didn't know any better) system and later on via e-mail to their security address, which resulted in the famous Calendar Serialization issue getting fixed. This JFileChooser issue just never got fixed. To be clear: after 2008, they never got back to me and I didn't harass them to fix it.
JFileChooser and FormView allow unsigned applets to read file-system structure (file/folder names), renaming files and moving files
Affected Operating Systems (at least): Windows XP, Windows 7
Affected Java Versions (at least): Java 6 update 23
Details
javax.swing.JFileChooser is a Java Swing component that allows the user to choose a file on the local filesystem. It cannot normally be used on an applet, because the initialization tries to read the user.home system property which is not permitted. So, if you try to do a "new JFileChooser()" you get a SecurityException and you won't get a handle to any object. And if you use the finalizer attack, you get an instance that isn't really functional.
This is where javax.swing.text.html.FormView comes in. It has a createComponent() method, which - with the right setup - creates a bunch of objects, one of them being a button, whose ActionListener creates a JFileChooser. That ActionListener can be extracted and then javax.swing.Timer can be used to execute the ActionListener.
Timer is used for executing ActionListeners in a timed fashion, and due to that nature, it executes them on a separate Thread which has no user code on the stack. In other words, it executes ActionListeners in a privileged context. Thus, the JFileChooser constructor runs fine.
So, a JFileChooser is created and displayed on the screen and the user can interact with it, but that doesn't do us much good, since we don't even have a reference to the JFileChooser. That's where Window.getWindows() comes in. It returns an array of all Windows accessible to the Applet, the JFileChooser being one of them. This way we get a reference to our JFileChooser instance.
What can we do with a JFileChooser? It only has methods for getting the selected file(s), once the user has made his selection and that's no good.
We can, however, define a FileFilter for the JFileChooser and that's interesting, because it'll receive File objects for each file in the current directory (so it can tell JFileChooser whether or not to display the file in question). This happens for the initial folder and also for any other folders, should the user navigate elsewhere with the JFileChooser. But since the user is not expecting to see a file chooser dialog, not a lot of navigation is to be expected.
There's an even better method to interact with the JFileChooser. Java AWT/Swing superclass java.awt.Component provides the method getComponents() which returns an array of child components. This way if you start at the top, in this case the JFileChooser, you can navigate to all the child components of the GUI, the buttons, the comboboxes, everything. Combine that with the fact that javax.swing.Timer can be used to execute the ActionListeners of any of these GUI components and you can pretty much simulate any user action on the JFileChooser.
So, we can view the file system structure of the machine running the applet. The JFileChooser has two additional interesting functionalities, which are the following: It can create empty folders and it can rename files and folders. Also, renaming files to "../newname" moves them toward the root in the filesystem and renaming files to "folder/newname" moves them into the folder. This means we can also move the files and folders.
Depending on other configuration like operating system, etc, this might be used for delayed Remote Code Execution. For example, a .jar might be moved from the Java Cache into the Java extension folder which has higher permissions. Or imagine an executable posing as an image, which gets renamed, then moved to a system folder.
Original bug report (2008)
Bug ID: 6764977
Review ID: 1379484
Date Created: Sun Oct 26 19:59:11 MST 2008
Type: bug
Customer Name: Sami Koivu
Customer Email: sami.koivu@gmail.com
SDN ID: sami.koivu@gmail.com
status: Waiting
Category: java
Subcategory: classes_swing
Company: IT7 Solution Technology
release: 6u10
hardware: x86
OSversion: win_xp
priority: 4
Synopsis: FormView allows untrusted applet read access to the filesystem structure
Description:
FULL PRODUCT VERSION :
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
javax.swing.text.html.FormView allows an untrusted applet to instantiate a JFileChooser in the event thread without untrusted applet code on the stack thus escaping intervention of a SecurityManager.
FormView can be subclassed and instantiated in such a way that the createComponent method returns a Component which contains a button whose ActionListener is the inner class BrowseFileAction.
This BrowseFileAction can then be extracted and executed via javax.swing.Timer on the event thread. The important thing to notice is that there will be no applet code on the stack and thus the applet security manager will allow the operation.
A JFileChooser dialog is opened. A reference to this dialog can be obtained via Window.getWindows(). Through this reference, using the AWt/Swing component structure (basically calling getComponent() to access the children of each GUI component) the filenames in the current (default) directory can be obtained. The dialog can also be manipulated in order to change the current browsing directory in the same fashion. Thus the whole directory structure on the system of the user running the applet could be obtained.
Unconfirmed, but it seems probable it would be possible to stimulate the file rename functionality as well, allowing an untrusted applet to rename any file on the system of the user running the applet.
It should also be noted that the dialog can be made invisible as soon as a reference to it is obtained (causing the dialog to only briefly appear on the screen).
I have a raw example of this available if absolutely necessary, but it is rather verbose and not very readable.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Stimulate FormView.BrowseFileAction to show a JFileChooser dialog.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Either the action object is somehow made inaccessible or security manager will perceive somehow that there is applet code behind this operation disallowing the operation.
ACTUAL -
A JFileChooser object is instantiated and displayed on the screen and can be manipulated in a manner that will at the very least invade the privacy of the web surfer.
REPRODUCIBILITY :
This bug can be reproduced always.
Evaluation from Sun Microsystems (2008)
It's perfectly correct to create JFileChooser under SecurityManager,
and in this case user will be able to browse the file structure,
it is *the code* who will not be able to do anything with those files
The bug's description doesn't show any way how an untrusted applet can read
the filesystem structure, we need more information
Posted Date : 2008-11-10 15:06:03.0
My response to evaluation (2008)
Ok, maybe the initial bug description was too superficial.
Here's a more detailed one. I'll do a bullet list and if necessary I can later be more specific on any single item.
* An instance of FormView's private inner class BrowseFileAction can be extracted.
* Said instance can be executed with javax.swing.Timer. The Timer class is used to executed ActionListeners in a timed fashion. When the Timer class is used to execute core ActionListeners only trusted code will be on stack and the security manager allows everything. BrowseFileAction is not the only problem. (BasicFileChooserUI.NewFolderAction can be used to create folders and there must be other vulnerable ActionListeners in the rt.jar, as well).
* When executed, BrowseFileAction opens a JFileChooser dialog. This alone might be acceptable or not. Keep reading.
* The java.awt.Window class has a method called getWindows() which according to the javadoc: "Returns an array of all {@code Window}s, both owned and ownerless, created by this application."
* Said method can be used to obtain a reference to the window which contains the JFileChooser instance. This goes something like:
JDialog dlg = (JDialog) Window.getWindows( ... );
JRootPane root = dlg.getRootPane();
JLayeredPane layered = (JLayeredPane) root.getComponent(1);
JPanel panel = (JPanel) layered.getComponent(0);
JFileChooser fc = (JFileChooser) panel.getComponent(0);
* (if you set your custom FileFilter on this instance, it will call your FileFilter's accept method once which each file of the current directory *the code* will be receiving this information)
* You can use the Container.getComponent(int) method on the JFileChooser to obtain all the direct and subcomponents of the JFileChooser. That is, the JComboBox subclass which controls the current directory and the sun.swing.FilePane object which contains a JList which contains the files in the current directory. You would go about it like this (YMMV):
JPanel panel = (JPanel) fc.getComponent(0);
JComboBox combo = (JComboBox) panel.getComponent(2);
* You can manipulate the JComboBox to change the current directory. You might, for instance, obtain the actionlisteners of the combobox, remove them from the combobox, set the seleted index of the combobox to a different value and then user javax.swing.Timer to execute the actionlisteners to update the JFileChooser.
* You can get the action for editing a filename from the FilePane in the same way described above. You can then execute the EditActionListener using javax.swing.Timer. This will cause the JFileChooser to display a JTextField for editing the filename. A reference to this JTextField can be obtained as described above (Container.getComponent(int)). The value of the text can be change by *the code* (setText(String) and another action can be invoked via javax.swing.Timer to tell JFileChooser that editing has terminated which will cause it to rename the file. Or move the file, if the file is renamed to "../filename" or "folder/filename".
Example - Caution, running this will rename and move a file on your system
(This works on Windows XP/Windows 7, file renaming doesn't work on Linux though it might be possible with extra effort)
It pops up a JFileChooser, goes to the first folder in the Location combobox, selects the 6th file and prefixes the name with "new" and moves it to the parent directory.
EDITED: This link is just the source code of the example. Safe to click. In order to run it you would need to compile it and create a page with an applet definition.
http://pastebin.com/mTCztGbQ
