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

[Jonathan Lu]

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