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

Charles Lee littlee at linux.vnet.ibm.com
Wed May 30 01:57:40 PDT 2012


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




More information about the awt-dev mailing list