On Monday 19 January 2009 16:33, 3BUIb3S50i 3BUIb3S50i wrote: > Toad wrote: > > - 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. Another variant would be to send an > embeddable but dangerous content type such as flash. You have fixed this? > > It's very dangerous and unacceptable. You should have disclosed this > problem and make FMS incompatible with Freenet to protect users.
I have tried to talk to them on several occasions and not had any success. And I refuse to run FMS now for reasons I have outlined - I do not have time to code review it, and it's had serious vulnerabilities in the past. Anyway, SomeDude said it had been fixed, or something very similar. > > On 1/19/09, Daniel Cheng <j16sdiz+freenet at gmail.com> wrote: > > 2009/1/19 Matthew Toseland <toad at amphibian.dyndns.org>: > >> 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. 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. > >> > >> But the bottom line is FMS cannot be bundled, 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 > > > > So why the wxWebkit browser be differ? > > > > FMS is written in C++ already, so you have no choice. > > That wxWebkit browser is a new project, why choose a language that you > > can't review? > > > > (no, i am not opposing the wxwebkit. i am just asking for some consistence > > over > > decisions.. i really hope fms can be bundled) > > > >> 0.2.X - and it cannot be integrated into the fproxy web interface, it > > > > With the wxWebkit browser using fcp directly, who care fproxy? > > > > (btw, i seldom use fproxy. > > Most of the time i use freenet was on fms / frost. > > Having fms page as homepage make more sense for me.) > > > > Also, fms have a web interface before my computer have dead > > -- SomeDude is very responsive to feature requests and willing to > > discuss about the message format. > > > > Freetalk keep changing its message formats, that's bad. > > I know those are "consent" of IRC discusion -- but it changing > > it every few weeks is not a good idea. > > Someone know the details should write down a specification -- > > in this way we may discuss the pros and cons and SomeDude > > may come up with some compatibility. > > > >> requires a separate daemon and is written in a different language. And > >> until > > > > separate daemon -- just a bundling issue. a good startup script fix it all. > > > > different language -- see above. > > > >> very recently it required a separate newsreader as well, making it > >> extremely > >> user hostile. > >> > >> 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. > > > > ugh. > > Let's see how p0s intergrate freetalk with the wxwebkit browser. > > > > > >> 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 > >> > > _______________________________________________ > > Tech mailing list > > Tech at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > _______________________________________________ > 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: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20090119/81512fbf/attachment.pgp>
