<AWT Dev> Behavior difference when open file dialog from applet
Charles Lee
littlee at linux.vnet.ibm.com
Wed May 30 08:57:40 UTC 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 security-dev
mailing list