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 >
