LWN: Comments on "Remote file inclusion vulnerabilities"

For the curious (but lazy)... cap.txt is CVE-2006-3773 exploit

Steve1980 — Wed, 10 Feb 2010 04:01:36 +0000

maybe this information can help you?

http://isc.sans.org/diary.html?storyid=2462

Remote file inclusion vulnerabilities

jrigg — Mon, 16 Oct 2006 20:33:23 +0000

Lots of ISPs still turn on register_globals. Mine does. Call me stupid (I use PHP after all), but isn't accepting form data without applying a paranoid level of checking first completely idiotic?

I suppose the problem is that PHP is an easy language to start programming in, so it allows people who perhaps shouldn't be programming at all to do stupid things. This is exacerbated by the fact that many of the introductory books avoid any discussion of security (I guess it's also an easy language to start writing about).

The obvious solution is to make it more difficult to use ;-)

Remote file inclusion vulnerabilities

Baylink — Sun, 15 Oct 2006 03:12:36 +0000

Is it really possible to avoid, now, linking to this?

PHP is an embarrassment

ldo — Sat, 14 Oct 2006 09:57:06 +0000

Unfortunately, I have to agree with you. PHP does seem to attract a certain class of users which is, shall we say, less than security-literate.

Remote file inclusion vulnerabilities

gypsumfantastic — Fri, 13 Oct 2006 11:02:40 +0000

Good god, PHP is an embarassment.

Using something that dreadful should form some kind of argument for Euthanasia. Rasmus should have been drowned for the public good.

Remote file inclusion vulnerabilities

roelofs — Thu, 12 Oct 2006 21:38:27 +0000

If you need another regular contributor here, I think you've found a good possibility. :)

I second that. Jake is a credit to the team.

Greg

For the curious (but lazy)... cap.txt is CVE-2006-3773 exploit

frazier — Thu, 12 Oct 2006 17:53:47 +0000

Thanks for the breakdown on this.

I use SMF standalone (no Joomla) and was wondering how this exploit worked.

Using search engines to find message boards for evil is common. I get an average of 3+ fake member registrations a day. The exploit here is simple: Post spam on the message board. For about 3 years I had my board to where anyone could post without approval, but in the last 6 months it escalated to the point of stupidity, so now I have to approve people. A shame.

Here's one of many spammed over boards out there (there's some sex spam on there along with insurance, gambling, drugs, and more):
http://wrfl881.org/forum/viewtopic.php?t=123&postdays...

That's page 1932, and all the spam on that (and some other pages) was added today.

That poor board has been drilled. It is linked directly from their home page:
http://wrfl881.org/

-Brock

For the curious (but lazy)... cap.txt is CVE-2006-3773 exploit

samj — Thu, 12 Oct 2006 14:47:16 +0000

http://webstorch.com/cap.txt downloads and executes http://webstorch.com/borek.txt, a perl daemon that looks like '/usr/local/apache/bin/httpd -DSSL' in process lists. It joins #save on bot-net.4irc.com using nick `whoami` followed by a random string of 7 alpha characters (eg www-dataabcdefg, nobodyabcdefg) and realname `uname -a` (eg Linux ownedbox 2.6.16-2-686 #1 Sat Jul 15 21:59:21 UTC 2006 i686 GNU/Linux), but only after receiving a 005 RPL_BOUNCE (presumably sent to prevent real clients connecting). If it receives 443 ERR_USERONCHANNEL it generates a new nick, just in case there was a clash. It then waits for commands including nick, eval, rsh, google, tcpflood, udpflood, httpflood, join and part.

Most are self explanatory, except the google command which searches altavista.com?!?! for something like '"Powered by SMF" com_smf site:xx' (where xx is a randomly selected ISO country code), the results of which will be called as 'http://victim.com/components/com_smf/smf.php?mosConfig_ab...'.

This is an exploit for http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-3773

PHP remote file inclusion vulnerability in smf.php in the SMF-Forum 1.3.1.3 Bridge Component (com_smf) For Joomla! and Mambo 4.5.3+ allows remote attackers to execute arbitrary PHP code via a URL in the mosConfig_absolute_path parameter.

It would probably be fairly easy to clean up the affected machines but to do so would potentially land you in as much hot water as the original author.

Remote file inclusion vulnerabilities

gerv — Thu, 12 Oct 2006 13:02:57 +0000

Excellent article. Well-written, at a non-patronising but accessible technical level, and not overly verbose. Bravo!

Remote file inclusion vulnerabilities

kleptog — Thu, 12 Oct 2006 11:39:00 +0000

I must admit, I find it astonishing the number of ways PHP allows you to shoot yourself in the foot. Perl also has a number of "magic" features, but they seem to all be much more cleanly and sensebly implemented and with tainting mode the risks become exceedingly small...

Remote file inclusion vulnerabilities

malor — Thu, 12 Oct 2006 08:51:27 +0000

This is a truly excellent article, a summary that is exactly complex enough to explain the issue thoroughly, with absolutely nothing else. Bravo!

It also sounds remarkably like corbet's voice.... I would have assumed it was him, barring Mr. Edge's name up top.

If you need another regular contributor here, I think you've found a good possibility. :)

Remote file inclusion vulnerabilities

StuHerbert — Thu, 12 Oct 2006 07:42:57 +0000

Default installations of PHP on Gentoo are not vulnerable to this form of attack. We switched off the allow_url_fopen option back in 2003 [1]. We have also long supported hardened-php.net's Hardened-PHP patch [2], which provides further protection against remote file inclusion. We'll shortly be shipping support for the Suhosin PHP security extension [3]; folks who want to test our support for that today can use the packages in the Gentoo PHP Project's overlay [4].

[1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/ph...
[2] http://www.hardened-php.net/hphp/
[3] http://www.hardened-php.net/suhosin/index.html
[4] http://overlays.gentoo.org/proj/php/

Best regards,
Stu