Domain: e-matters.de
Stories and comments across the archive that link to e-matters.de.
Comments · 9
-
Also...
There's more. This January, 12 remotely exploitable buffer overflow bugs were found in Gaim. Less than a week ago, the SuSE security team found another remotely exploitable buffer overflow. (Scroll down.) Those found in January should be fixed as far as I can tell.
-
Re:Bugfree OSSWell, according to e-matters, a series of 8 different buffer overflow bugs were disclosed to gaim developers on January 4, 2004. A new gaim client (0.75) was released on January 10, but this only fixed one of the overflows and introduced four new ones.
On January 15, gaim development was emailed patches for all 11 existing bugs. A patch was added to CVS that evening, but there was no 0.76 release and no public disclosure by gaim dev (at least on their Sourceforge page - there may have been something sent to the mailing list). On January 23, e-matters let gaim dev know that they would release the bug report on January 26. On January 25, gaim dev replies that there is no timeframe for a 0.76 or bug-fix release. On January 26, e-matters publishes the bug report.
On January 28, gaim dev responds with a note saying they are far from a 0.76 release and provides a link to the FreeBSD source patch. Not much use to your average teenage Windows IMer. There may have been an executable patch, but I can't find any evidence of one.
On April 1, gaim release 0.76, the first release with the bug fixes is released. This has taken so long because:
Well, life has struck hard on the Gaim camp and we've been too busy with other things to provide with prompt Gaim releases.
This is no slam on gaim - the devs have lives outside of gaim and I'm glad they're providing a great OSS client. But like anything, there are pros and cons to both OSS and commercially developed software. Assuming that OSS is always more responsive, more bugfree, and better in every other way is naive. There are tradeoffs involved in libre software - most are well worth it, but there can be downsides occassionally too.
-
Re:Sourceforge...
Well, as far as I know, SourceForge uses pserver only for anonymous CVS access. Presumably, the anonymous CVS uses a read-only filesystem. If someone were to exploit this vulnerability, it would probably be pretty difficult for them to cause any problems.
Developers have access over SSH, and hopefully only have access to their project. There are obviously some concerns with malicious developers or people breaking into a developer's account, but the chances are pretty slim.
I don't think this was mentioned anywhere else, but the original annoucement includes a note about SourceForge finding a problem with the security patch breaking compatibility with some versions of WinCVS and TortoiseCVS. -
Re:Is it the same flaw?No whoever submitted the article to Slashdot was confused. If you read the news.com article carefully it is clear that they're separate issues.
But just to make things clearer here are the links to the advisories:
Subversion
CVSI also put up a more clear description of the Subversion problem up on subversion site.
-
Re:Is it the same flaw?No whoever submitted the article to Slashdot was confused. If you read the news.com article carefully it is clear that they're separate issues.
But just to make things clearer here are the links to the advisories:
Subversion
CVSI also put up a more clear description of the Subversion problem up on subversion site.
-
Interesting page
Take a look here. I specially like the last paragraph about "reimplementing" the bug.
-
Re:PHP Module Replaced
In general, that's good advice. However, the module in question was updated to 4.1.2 one day after the hole was made public (February 27, 2002).
It's taken Apple over a month to provide the same fix.
FYI, the actual issue is the PHP file upload security hole. For more details see:
-
The important facts
This is a very high impact vulnerability, mod_php is the worlds most popular Apache module, maybe the most popular web script language. (no flamewars intended, it IS popular among a lot of people whether you like it or not).
However, one line in the config should according to php.net disable the vulnerability :
file_uploads = off
(When tested phpinfo(); gives "no value" at my site)
One file needs to be patched for all PHP versions, get the patch here :
php.net/downloads.php
Patch like this:
1. Enter ../src/php-4.0.x/main dir
2. patch < pathtodiffile/rfc1867.c.diff-4.0.6
3. build either the DSO module or build apache with static php
The "full" advisory is here :
security.e-matters.de
now, PATCH! -
Microsoft is just plain dumb
Microsoft is just plain dumb, here is already the next Internet Explorer securityhole...
http://security.e-matters.de/advisories/012001.htm l
just my 2 cents