Changeset 5052 a589a8dbde79 question
Christopher Meyer
christopher.meyer at rub.de
Fri Feb 24 16:10:38 UTC 2012
Hi Seán,
you're absolutely right. That's the thing I missed.... I wasn't aware of the
fact that indexOf deals with ASCII format chars.
The fix seems to be absolutely ok. In any case, a smart solution to safe
operation calls!
Sorry for the confusion.
Regards,
Chris
On Friday 24 February 2012 15:31:06 Seán Coffey wrote:
> hold on,
>
> the indexOf test will match with those ASCII format chars.
>
> i.e
> "/.\56/.\56/.\56/etc/passwd".indexOf("..") returns 1.
>
> Is the fix still ok then ?christopher.meyer at rub.de
>
> regards,
> Sean
>
> On 24/02/12 14:09, Seán Coffey wrote:
> > 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 ("
> >>
> >> +
> >>
> >> b
> >> u
> >> f
> >> [
> >> i
> >> n
> >> d
> >> e
> >> x
> >>
> >> -
> >>
> >> 1
> >> ]
> >>
> >> +
> >>
> >> "
> >> )
> >> :
> >>
> >> "
> >>
> >> +
> >>
> >> i
> >> d
> >> )
> >> ;
> >>
> >> 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
______________________________________
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
More information about the security-dev
mailing list