EFnet Paralyzed By Vulnerability

An anonymous reader writes "EFnet member Fionn 'Fudge' Kelleher reported several vulnerabilities in the IRC daemons charybdis, ircd-ratbox, and other derivative IRCds. The vulnerability was subsequently used to bring down large portions of the EFnet IRC network." By crafting a particular message, you can cause the IRC daemon to call strlen(NULL) and game over, core dumped.

Comments

Stop writing things in C/C++

[Anonymous Coward]

Stop writing massive projects in languages that don't protect against this shit. It's been how many decades and people still haven't learned this.

There are dozens, if not hundreds, of languages with array bounds checking (and also garbage collection, for you shitwits who are prone to memory leaks). Lisp, Java, C# are three you can look at.

"B-b-but, MUH PERFORMANCE!". No, shut the fuck up, if you're a programmer worth your weight in salt then you'll structure your program not to make unnecessary heap allocations.

Re:C strings strike again!

[cheekyboy]

Hmm

Option 1 : 50 dozen try/catches every where making java slower, and coding more manual.

Option 2 : If length() returned zero even on a null object, it still is sort of correct, the string is zero sized.

Coding should be made easier not bloated.

Should there be 100000000 instances of checking for pointer before calling strlen(), or should strlen() it self check for ptr?

This is where libc sucks, so just make your own strlen() from libc, as a static strlen(), which behaves nicer. A length of a 'NULL' object, well... yes, it is zero. Its length is not known or undefined which is bloody zero.

I personally think that the responsibility on checking input args goes to the function, not the caller parent. You cannot delegate that to the caller which can make mistakes, prevent all mistakes in the library itself.

We are not on a 286 any more. And besides either way, there is a check for the pointer, but as I said its better in the 'black box function'

LIBC - you fail.