Re: Behavior difference when open file dialog from applet

[Charles Lee]

Hi security-devs,

I'd like to sponsor this patch. Would any security guys please have some 
time to review this patch?

On 05/03/2012 04:26 PM, Jonathan Lu wrote:
Hello, how about just change the code like following patch by adding a 
security check point before invoking the native dialog.

http://cr.openjdk.java.net/~luchsh/webrev_gtk_file_dialog/

Best regards!

- Jonathan

On 04/23/2012 06:14 PM, Jonathan Lu wrote:
Basically the existance checking of files and directory without 
explicitly granted permissions do not look very friendly to me 
especially for applet code from the web. This might be a helpful way 
for hackers to infer OS version, user habit or software config from 
the directory layout retrieved by a file dialog.

Any comments from the security list?

best regards!
-Jonathan

On 04/20/2012 08:33 PM, Anthony Petrov wrote:
OTOH, using a file dialog may allow one (with a little help from a 
user) to check a file or a directory for existence which may be 
considered a security vulnerability. This is actually the reason the 
exception is thrown by XFileDialogPeer in the first place: it gets 
thrown when the code calls File.isDirectory() when setting the 
initial directory for the dialog.

Not sure if this ability is much useful by itself, or if this 
vulnerability is "convenient" for hackers to use since it involves 
the user, but still this doesn't feel like a benign thing to me.

What do security experts think about that?

--
best regards,
Anthony

On 4/19/2012 8:31 PM, Artem Ananiev wrote:
Hi, Jonathan,

you're right, GTK and X file dialogs behave differently when 
SecurityManager is installed. However, instead of changing GTK 
dialogs, I propose to correct X dialogs, so they don't throw 
security exceptions.

Indeed, application may create arbitrary java.io.File objects 
without any permissions. File permissions are only checked when 
application tries to read from, or write into, or just open the 
file. AWT file dialogs are about getting File objects, they don't 
provide access to File content (be it a regular file or a 
directory), so I don't see any reasons to throw exceptions.

What do you think about it?

Thanks,

Artem

On 4/18/2012 11:02 AM, Jonathan Lu wrote:
Hello, is anybody interested in this problem?

it seems to be a generic question of how to control security 
access in
JNI native implementation of JDK.
And consider the behavior differences, is it neccessary to 
reimplement
Gtk file dialog in the same way as X dialog?

Regards
- Jonathan

On 04/11/2012 08:36 PM, Jonathan Lu wrote:

Hi awt-dev,

I found a behavior difference when open file dialog from an 
applet, bug
7160238 has been created for this issue.
Here's the tiny test case to helping reproduce the problem,

/*
* Copyright (c) 2012 Oracle and/or its affiliates. All rights 
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or 
modify it
* under the terms of the GNU General Public License version 2 
only, as
* published by the Free Software Foundation.
*
* This code is distributed in the hope that it will be useful, but
WITHOUT
* ANY WARRANTY; without even the implied warranty of 
MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public 
License
* version 2 for more details (a copy is included in the LICENSE 
file that
* accompanied this code).
*
* You should have received a copy of the GNU General Public License
version
* 2 along with this work; if not, write to the Free Software 
Foundation,
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
*
* Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 
94065 USA
* or visit www.oracle.com if you need additional information or 
have any
* questions.
*/

/*
* Portions Copyright (c) 2012 IBM Corporation
*/

import java.applet.Applet;
import java.awt.Button;
import java.awt.FileDialog;
import java.awt.Frame;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

public class FileDialogTest extends Applet {
@Override
public void init() {
Button button = new Button("Open FileDialog");
add(button);
button.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent event) {
Frame f = new Frame();
FileDialog dialog = new FileDialog(f, "FileDialog");
dialog.show();
}
});
}
}

Embeded it into an HTML document, test.html, then run 
appletviewer with
following two commands,
appletviewer -J-Dsun.awt.disableGtkFileDialogs=true test.html
appletviewer -J-Dsun.awt.disableGtkFileDialogs=false test.html

The result will be different, -J-Dsun.awt.disableGtkFileDialogs=true
will throw AccessControlException, but
-J-Dsun.awt.disableGtkFileDialogs=false will continue to open a file
dialog.

According to the specification:
The basic applet security model is an all or nothing proposition. 
If you
get a security certificate, you can give the applet full access 
to the
user's system. Without it, the applet has virtually no access at 
all.

Since file dialog displays the content of user's file system, so it
absolutely needs file system read permmission, right? but for Gtk 
File
Dialog, it just works fine without exceptions. I don't think this
behavior is following the spec here, right? In OpenJDK's source 
code,
GtkFileDialogPeer will create a native GTK file chooser widget 
and keep
a native pointer, does this leave a breach to Java applet's security
model?

Cheers!
- Jonathan







--
Yours Charles