* Matthew Toseland <toad at amphibian.dyndns.org> [2009-01-19 13:02:31]:
> There were at least:
> - A lack of validation on the captchas page which enabled collecting users IP
> addresses. This involved putting newlines into the headers in order to send
> extra headers and in particular redirects, and was actively exploited by
> nextgens to collect IP addresses.
Unless you can prove it that's defamation ;)
> Another variant would be to send an
> embeddable but dangerous content type such as flash. You have fixed this?
> Great.
> - A format string vulnerability. I believe this enabled remote code exec, or
> at least a segfault. This was fixed, but it's a great demonstration of why
> you need to be *really* careful when using C/C++ for security critical code.
>
Well, those are the two obvious flaws I found when I reviewed the code a
while ago... I have no doubt that digging futher I can find more.
> But the bottom line is FMS cannot be bundled,
Cannot be bundled "as is". I don't think we should disregard a program
just because it has some security history.
> therefore it is not worth my
> time to review it. FMS is written in C/C++ and therefore would be difficult
> for me to review - I missed the format string vulnerability when I reviewed
> 0.2.X - and it cannot be integrated into the fproxy web interface, it
> requires a separate daemon and is written in a different language. And until
> very recently it required a separate newsreader as well, making it extremely
> user hostile.
>
Those are valid points. I would add:
- they are legal implications with bundling someone else's code
(Especially from an anonymous source: what if he is infringing
someone's copyright? Who would be responsible for it?)
- there is no way of reliably contacting upstream
(I couldn't contact SomeDude without publicly disclosing both
vulnerabilities; At the very least he should publish some crypto
keypairs so that we could ensure only him can read it -GPG keys would be
perfect-)
- reviewing the code is a PITA because no SCM is used
(that's a criticism I've already made in the past)
- FMS is adding more and more dependancies on 3rd party libs we
don't know and don't have the resources to audit
> Freetalk on the other hand can be bundled, and has a better architecture,
> enabling WoT to be used for WoT-based apps other than forums. Thus I have
> been helping p0s with Freetalk.
>
I do think that the architecture of WoT/Freetalk is cleaner too
> On Sunday 18 January 2009 16:14, 3BUIb3S50i 3BUIb3S50i wrote:
> > >From FMS
> >
> >
> > SomeDude at NuBL7aaJ6Cn4fB7GXFb9Zfi8w1FhPyW3oKgU9TweZMw wrote:
> > > falafel at IxVqeqM0LyYdTmYAf5z49SJZUxr7NtQkOqVYG0hvITw wrote:
> > >> me again, Toad on FMS:
> > >>
> > >> [16:14] <toad_> Tommy[D]: therefore it is not worth my time to code
> > >> review it, especially as it's had obscure C-based remote code exec vulns
> > >>
> > >> anyone know what these "remote code exec vulns" were?
> > >
> > > There was an issue with form submission that would let another site pass
> > > its own form parameters to FMS. Also, before the captchas were
> > > validated, it could have been possible to put some nasty code in them
> > > instead of an image.
> > >
> > > Anyway, this argument is about as valid as saying that since Freenet has
> > > known vulnerabilities, and you aren't really anonymous using it, you
> > > shouldn't run it at all.
> > >
> > > This looks like a typical reaction:
> > > A bug in Freenet: It's OK, it doesn't really leak a whole lot of info
> > > about our users. We'll fix it eventually.
> > > A bug in FMS implementation: OMG, STOP USING IT FOREVER!!!!
> _______________________________________________
> Tech mailing list
> Tech at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/tech/attachments/20090119/2867c8b0/attachment.pgp>
