Changeset 5052 a589a8dbde79 question

[Seán Coffey]

thanks for raising this point Chris.

we certainly don't want any windows for such an attack. I'll revisit this.

regards,
Sean.

On 24/02/12 13:31, Christopher Meyer wrote:
> Hi,
> please correct me if I'm wrong, but the Changeset 5052 in ZoneInfoFile could
> maybe draw an unexpected SideChannel at System.err.
>
> Please have a look at the following:
> TimeZone tzExistent = TimeZone.getTimeZone("/.\56/.\56/.\56/etc/passwd");
> will walk the following path:
>
> java.util.TimeZone:
> public static synchronized TimeZone getTimeZone(String ID)
> private static TimeZone getTimeZone(String ID, boolean fallback)
> private static final TimeZone parseCustomTimeZone(String id)
> sun.util.calendar.ZoneInfo
> public static ZoneInfo getZoneInfo(String id)
> private static ZoneInfo createZoneInfo(String id)
> private static byte[] readZoneInfoFile(final String fileName)
>
> where it is checked if it contains ".."
>
> ileName.indexOf("..")>= 0
> (which indeed it doesn't) - no more checking at this point, necessary path
> checks are dropped for the sake of performance. When passed to
>
> File file = new File(ziDir, fileName);
>
> it will evalute fine to /../../../etc/passwd. Since the operation takes place
> inside a doPrivileged block the file could be read (if present) without
> SecurityException, even in an Applet. The attacker would succeed with a
> directory traversal. No big deal due to this point, since no information is
> handled to a potential attacker.
>
> But when looking at the return path we find the following in private static
> ZoneInfo createZoneInfo(String id):
>
> System.err.println("ZoneInfo: wrong magic number: " + id);
> or
> System.err.println("ZoneInfo: incompatible version ("
>                                     + buf[index - 1] + "): " + id);
>
> So if an attacker manages to access System.err (one could think about
> capabilities of LiveConnect or some related technologies...) he would be able
> to detect the presence of files on the victims system. This would be clearly a
> violation of the applet sandbox.
>
> In my opinion the impact is not that big, but it increases an attackers
> surface.
>
> Do I miss something or got something wrong or this this an issue that should
> be fixed?
>
> Regards from Germany,
> Chris
>
>
> Blog on Java security and related topics:
> armoredbarista.blogspot.com
>
> ______________________________________
>
> Dipl.-Ing. Christopher Meyer
>
> Horst Görtz Institute for IT-Security
> Chair for Network and Data Security
> Ruhr-University Bochum, Germany
>
> Universitätsstr. 150, ID 2/415
> D-44801 Bochum, Germany
> http:// www.nds.rub.de
>
> Phone: (+49) (0)234 / 32 - 29815
> Fax: (+49) (0)234 / 32 - 14347
>
>