On Saturday 08 August 2009 21:12:27 3BUIb3S50i 3BUIb3S50i wrote:
> Forwarded from FMS:
>
> SomeDude at NuBL7aaJ6Cn4fB7GXFb9Zfi8w1FhPyW3oKgU9TweZMw wrote :
> > djk at isFiaD04zgAgnrEC5XJt1i4IE7AkNPqhBG5bONi6Yks wrote:
> >> cwlrao41 at f2qqcdkajvdGGdtRf33S6GfW2dYFMfc4sR6BVPg8vPQ wrote:
> >>
> >>> SomeDude at NuBL7aaJ6Cn4fB7GXFb9Zfi8w1FhPyW3oKgU9TweZMw wrote :
> >>>> cwlrao41 at f2qqcdkajvdGGdtRf33S6GfW2dYFMfc4sR6BVPg8vPQ wrote:
> >>>>> Is FMS possibly affected by recent XML vulnerability? Does it do XML
> >>>>> parsing itself or using some library (maybe statically linked)?
> >>>> FMS uses libPoco for XML parsing. What vulnerabilities are you
> >>>> referring to?
> >>>>
> >>
> http://tech.slashdot.org/story/09/08/05/1555219/XML-Library-Flaw-mdash-Sun-Apach
> >>> e-GNOME-Affected
> >>> http://www.cert.fi/en/reports/2009/vulnerability2009085.html
> >> Woah!
> >> "Vendor Information
> >> Python libexpat
> >> Apache Xerces, all versions
> >> Sun JDK and JRE 6 Update 14 and earlier
> >> Sun JDK and JRE 5.0 Update 19 and earlier
> >> "
> >> Does this really mean that Java code running on these jvms is vulnerable
> to
> >> remote code execution?
> >>
> >> Does this impact fred? (kind of doubt it)
> >>
> >
> *> I have done some testing with the type of vulnerability they are talking
> > about here. While this particular vulnerability is about DoS and remote
> > code execution, the same type of vulnerability can be used to open a
> > connection to any computer, and doesn't seem to be limited to the Java
> > versions listed above. What I found with my testing wasn't very
> > encouraging.
> >
> > Let me first say that I am using Sun JDK Update 15. I tested 3 Freenet
> > apps, jSite (0.7.1), Thaw (0.7.10), and Frost (2009-03-14), to see if
> > they are vulnerable specifically to the remote connection type of
> > exploit. I had the exploit code connect to a web server on another
> > machine and I watched the web log for connections.
> >
> > I added the exploit code to the jSite config file, started it up, and
> > sure enough the exploit code caused a connection to the remote machine.
> > Now jSite doesn't do any uploading and downloading of XML files from
> > other users, so it's not an immediate threat, but the exploit ability
> > remains there.
> >
> > With Thaw, I exported an index, added the exploit code to it, and
> > reimported it. The code was triggered again, and a connection was made
> > to the remote machine. This is very serious, as a malicious user could
> > add the exploit code to an index and have it executed when another Thaw
> > user downloads and parses that index.
> >
> > In Frost I exported the identity xml file and added the exploit code to
> > it. When I imported the file, the code was not executed. I tried
> > several different variations of the exploit code, but was unable to get
> > Frost to run it. I'm not sure if Frost is using a different XML parser
> > than jSite and Thaw, but no matter what I did, I could not get the
> > exploit code to run. That's not to say it can't be exploited, just that
> > I couldn't find a way to run this particular exploit.
> >
> > As I mentioned in another message, the XML parser in the Poco library,
> > which FMS uses, doesn't seem to parse this type of exploit by default
> > either.
> >
> > It appears that there are XML parsers that are vulnerable and some that
> > are not, and due to the nature of this exploit, it would be best to wait
> > to hear from the developer of any Freenet applications you use to
> > confirm that the exploit doesn't affect them before you run their
> > application. This exploit is extremely threatening if you value your
> > anonymity.
> *
>
If you have the exploit please email me it so I can test the various plugins
that use XML against it. Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/tech/attachments/20090809/6b84ad35/attachment.pgp>
