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