<AWT Dev> Behavior difference when open file dialog from applet

[Jonathan Lu]

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
>>>>>
>>>>>
>>>>
>