Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×

156 comments

Sigh... (5, Funny)

MightyMartian (840721) | about a year and a half ago | (#42437125)

1998 called and want their attack vector back.

Re:Sigh... (4, Funny)

skovnymfe (1671822) | about a year and a half ago | (#42437147)

It's retro cracking. Old is the new new, y'know?

Re:Sigh... (0)

Anonymous Coward | about a year and a half ago | (#42437269)

+1 Funny But Sad, like the tears of a clown.

Re:Sigh... (0)

Anonymous Coward | about a year and a half ago | (#42438393)

I hate that song. I always think they're talking about me when it comes on.

Re:Sigh... (0)

Anonymous Coward | about a year and a half ago | (#42439533)

You and me both. *brohug*

Re:Sigh... (2)

faedle (114018) | about a year and a half ago | (#42437429)

A 1998 attack vector for a 1992 network.

Re:Sigh... (1)

NotQuiteReal (608241) | about a year and a half ago | (#42438133)

You can still do this in a modern language... like C#/.NET

string s;

if (s.Length....

blammo - you should have checked if s was null first... Oh, and use that fancy try/catch stuff, all the cool kids do!

Objective-C nil (1)

tepples (727027) | about a year and a half ago | (#42438199)

blammo - you should have checked if s was null first

Unless you're using Objective-C, where the "nil" is a special object that implements all messages (that is, methods) as a no-op that returns a nil.

Re:Sigh... (0)

Anonymous Coward | about a year and a half ago | (#42438435)

Actually, trying to compile code like that will result a compiler error in C#.NET (at least using the MS compiler)

There are a lot of improvements to avoid obvious stupidity like that.

Re:Sigh... (0)

Anonymous Coward | about a year and a half ago | (#42438647)

Or use stuff like Java's @NotNull / @Nullable assertions (obviously putting the emphasis on @NotNull instead of the other ; )

Since JetBrains started including these in IntelliJ IDEA, with real-time checking (even on incomplete ASTs), I've probably eliminated about 99% of all the NullPointerException I got in Java. (great thing is: in a team with a mixed dev environment it can work transparently --it appears in the source code, but not in the .java source file--, giving me a gigantic edge but not my non-IDEA co-workers ; )

So in an "even more modern" language the very concept of null can be replaced very often, by objects which you can guarantee can never ever be null. It may not work *all* the time, but in my experience it works in 99% of the cases.

@NotNull is not exactly new btw... It's quite a few years old.

And of course there are languages which have an even saner concept of null / nil (or both, like Clojure, in which you have lots of nil but can still get an occasional Java NPE).

Re:Sigh... (2)

waspleg (316038) | about a year and a half ago | (#42438221)

You're laughing but I had to tell the developers of a small indie MMO, with-in the last year, that their ircd was vulnerable to remote exploits and it was running on the same thing that hosted the game itself, true story.

What the EF? (0)

Anonymous Coward | about a year and a half ago | (#42437151)

How did this happen?

Re:What the EF? (1, Funny)

X0563511 (793323) | about a year and a half ago | (#42438771)

EFnet is some crappy IRC network people go to for help until they find out about freenode.

C strings strike again! (3, Insightful)

cheesybagel (670288) | about a year and a half ago | (#42437153)

This is the problem you get when your strings don't know their allocated size like in that ghastly language Pascal.

Re:C strings strike again! (2, Insightful)

cheesybagel (670288) | about a year and a half ago | (#42437161)

Not to mention the whole C issue where pointers to something and arrays of something are sort of the same but not really.

Re:C strings strike again! (-1)

Anonymous Coward | about a year and a half ago | (#42437347)

>This is the problem you get when your strings don't know their allocated size like in that ghastly language Pascal.

Maybe you should go back to college and learn about software engineering, or stick to HTML editing

Re:C strings strike again! (1)

cheekyboy (598084) | about a year and a half ago | (#42437699)

Yes too much management needed in C.

Even if you had a *ptr holding the data type. You have to check.

Pitty intel didnt implement string functions in the CPU.

But damn, the libc guys should check input pointers themselves.

Re:C strings strike again! (3, Informative)

Lunix Nutcase (1092239) | about a year and a half ago | (#42437767)

Pitty intel didnt implement string functions in the CPU.

They did. [pku.edu.cn] Welcome to decades ago.

Re:C strings strike again! (1)

oursland (1898514) | about a year and a half ago | (#42439453)

The Intel 8086 included string instructions. It was released in 1978, which puts these instructions back at 34 years ago. Decades? A third of a century ago!!!

Re:C strings strike again! (2)

nedlohs (1335013) | about a year and a half ago | (#42438881)

But damn, the libc guys should check input pointers themselves.

And do what? Return a clearly wrong value so the caller can blindly continue? Burn some cpu on every call so that a broken caller can run a little longer and mysteriously crash later on or maybe just produce garbage output?

That said, undefined behavior is undefined, if I was writing a libc it'd have to return 97 just for the heck of it.

Re:C strings strike again! (1)

TheRaven64 (641858) | about a year and a half ago | (#42439945)

Return 0, or -1? The fault isn't that of the libc developers, of course, it's the fault of the specification writers, who wanted to make it possible to save a few bytes. The other one that always irritates me is strcmp(), where it should be trivial to say that two NULL inputs are the same, but otherwise NULL comes before any other input and then you wouldn't need to bracket every single call in a NULL check. And since it's not part of the standard, even if one libc did do something sensible, you couldn't rely on it and so you'd end up with NULL checks before and after the call, so that libc would seem slower.

Re:C strings strike again! (2, Informative)

ls671 (1122017) | about a year and a half ago | (#42437223)

An uncaugh NullPointerException on a call to aString.length() in java would have the same effect and kill the running Thread, the program if it is the main Thread.

http://stackoverflow.com/questions/5796103/strlen-not-checking-for-null [stackoverflow.com]

Re:C strings strike again! (0, Flamebait)

cheekyboy (598084) | about a year and a half ago | (#42437795)

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.

Re:C strings strike again! (2)

VGPowerlord (621254) | about a year and a half ago | (#42438255)

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

null isn't an object in Java, which is where the problem is coming from.

Re:C strings strike again! (0)

Anonymous Coward | about a year and a half ago | (#42438809)

FYI try/catch doesn't make the execution slower. Each try/catch adds info to a lookup table in the class file and ONLY when an exception is thrown is that table inspected for a try/catch that would handle the thrown exception.

Re:C strings strike again! (2)

TheRaven64 (641858) | about a year and a half ago | (#42439951)

That is very implementation dependent. What you say is true for C++ (on most modern systems, which use the 'zero-cost' exception model. I think iOS is the only exception, which uses setjmp() / longjmp() and so has expensive exceptions, unless they've fixed it recently). In Java, because exceptions are so common, this is often significantly slower and so functions return two values and the call is followed by a (statically hinted as not taken) branch on the 'an exception was thrown' value, which then jumps into the catch / finally block and checks what the exception was.

Re:C strings strike again! (1)

muridae (966931) | about a year and a half ago | (#42438889)

So, you have a pointer to string S, and you want *S.length() to check whether S is null? Do you propose that all functions on null pointers return 0? If so, how would you determine if it's a null pointer, or if the answer really was 0?

Re:C strings strike again! (0)

isorox (205688) | about a year and a half ago | (#42438933)

So, you have a pointer to string S, and you want *S.length() to check whether S is null? Do you propose that all functions on null pointers return 0? If so, how would you determine if it's a null pointer, or if the answer really was 0?

If (s==null)

Re:C strings strike again! (2)

TheRaven64 (641858) | about a year and a half ago | (#42439957)

This is exactly what Objective-C does. The method lookup function (objc_msgSend() and friends) contain a short-circuit path that returns 0 if the receiver is nil.

Re:C strings strike again! (1)

Teckla (630646) | about a year and a half ago | (#42437815)

An uncaugh NullPointerException on a call to aString.length() in java would have the same effect and kill the running Thread, the program if it is the main Thread.

The JVM would continue running as long as there are running non-daemon threads. Whether or not it is the main thread is irrelevant.

You are correct, however, that calling .length() on an object of type String that is null will throw a NullPointerException; however, it may or may not kill the current thread. It depends on whether or not the exception is caught, which is often the case, especially in servers where robustness is important.

Re:C strings strike again! (1)

the eric conspiracy (20178) | about a year and a half ago | (#42438413)

It isn't a matter of checking every object.

Just the ones that come from outside.

That takes lazy^stupid to miss, not just lazy/stupid.

Re:C strings strike again! (1, Interesting)

nenolod (546272) | about a year and a half ago | (#42437301)

This was a NULL-pointer exception, not a buffer issue. But I do agree that it makes more sense to invest in building IRCd software which is written in string-safe and pointer-safe languages. Mozilla's rust language [rust-lang.org] , for example looks promising for use in IRCd. The main thing is that we need a language which provides scalable data structures, as servicing IRC messages involves many data lookups.

However, it is easier for most people hacking on IRCd to just pick up a 2.8-derivative.

Theoretical way to get size of C string (2, Interesting)

Anonymous Coward | about a year and a half ago | (#42437411)

Using error handlers, & two pointers (this goes for ANY array, & strings are just arrays of characters/array of char):

---

1.) You send two pointers into/@ the array/string buffer allocated, as follows:

2.) 2nd "double-sized" one (positionally) is ALWAYS double the size (position) of the 1st.

3.) When the 2nd "double size of the first" FAILS (& the err handler catches it, ala try-catch/try-except type constructs)?

4.) The error handler passes back the size of the 1st "half-size pointer" location, & doubling it gives you the size of the array/string!

---

* THIS COULD BE USED TO TEST THE SIZE OF THE ALLOCATED SPACE FOR THE STRING BEFORE WRITING TO IT, first!

** ONLY PROBLEM IS, original C & Pascal implementations DON'T HAVE ERROR HANDLERS like Try-Catch/Try-Except/On Error GoTo etc./et al that C++ &/or Object Pascal do!

BUT YOU CAN "RIG IT" for error handling ala -> http://blog.staila.com/?p=114 [staila.com]

(@ least afaik - I haven't worked with THOSE languages in almost 20 yrs. & certainly not ALL implementations, more modern ones MAY... I don't even remember if there is a way of "rigging" that into them vs. structured error handling built into their compilers).

---

However - Delphi Object Pascal has this (but not sure on original pascal implementations though, been DECADES since I did Turbo Pascal for DOS even).

Then - Even C has strlen... & that could be used to check this "hole" they are having a problem with, don't ya think?

* Any takers on that? Should work, in theory @ least, on C strings & their size... because it does on arrays you don't know the length of!

Lastly?

STRAIGHT Pascal, for lack of a better expression here (not Delphi, that's Object Pascal) could be done the same since it has pointers & can do the same type of testing the string array buffer, & it too, by the by - since it has a LENGTH function that can determine the size of a string as well...

You can "bust my balls" on this one IF I am off, I didn't read the article, but... it's an idea here, that *MAY* work!

APK

P.S.=> And, there you are... & not that THIS really matters, but, ONCE YOU HAVE THAT - you can "Trim" function the string chopping off the rest of it leading or trailing: There's examples of that in C & PASCAL all over online!

(I know for a fact Delphi Object Pascal has trim/rtrim/ltrim type functions built in, and C++ has functions you can find even online for it, since I don't recall it being part of the "std. string library of functions" but it may be in diff. dialects of it though, like C++ Builder) if its blanks etc./et al...

... apk

Re:Theoretical way to get size of C string (2, Funny)

Anonymous Coward | about a year and a half ago | (#42437451)

Can these solutions be used in a Hosts file?

LOL, Ok read (0)

Anonymous Coward | about a year and a half ago | (#42437503)

I don't even *KNOW* if this method will work on straight (original) implementations of classical C or PASCAL to be honest!

* It's been AGES since I worked with either (favoring C++ &/or Object Pascal over C & Pascal)...

Fact is - I may be COMPLETELY off, & what I am putting out, for C & PASCAL (original implementations that is, ala Bell Labs/AT&T + Kernighan & Ritchie OR Niklaus Wirth, respectively) will even work here...

(Being honest here - it's New Year's Eve, & LOL, I have been 'tipping a few' already with my neighbors, & stopped back home for more beer to bring over to their get together, & am NOT "@ my best" right now, if you know what i mean!)

LOL, gotta jet...

APK

P.S.=> Just 'putting out' / "bouncing ideas off others" here is all... I liked IRC in my day is why (Dalnet where I was an admin on their "official Windows help channel" endorsed by K. Marden Bey, creator of MIRC in fact, circa 1994-2000)...

... apk

Re:Theoretical way to get size of C string (1)

webmistressrachel (903577) | about a year and a half ago | (#42438977)

That's not sporting at all. He actually posts something informative about something else and you troll him? OK, I'm known for teasing apk, but he does something positive and you try to pull him down? Not fair. Rachel. Not bloody Barbie or whatever, Rachel.

Re:Theoretical way to get size of C string (1)

ls671 (1122017) | about a year and a half ago | (#42437659)

From your link:
"It makes the function look complicated as it has multiple exit points (return statements)."

hmm... you mix up 2 things. It is more like you add complexity by introducing multiple exit points.

There is ways around it you know... Beginning your fucntion with a temporary variable set to NULL and returning that temporary variable in one exit point at the end of your function is one.

I didn't write it (you must be drunk too, lol) (0)

Anonymous Coward | about a year and a half ago | (#42438291)

It's only a link I referenced regarding error handling & how it can potentially be done in C or PASCAL (since the original Bell Labs/AT&T/Kernighan Ritchie C, &/or the original Niklaus Wirth PASCAL don't have try-catch/try-except built into them like JAVA, or Borland Object Pascal do, for example) & the IRC folks' hassle is their stuff's written in C (& I am not sure if the implementation/compiler they're using has err-handers/exception handlers, but classical C doesn't)...

* It's NEW YEAR'S 2013 THOUGH (12/31/2012), the world didn't end either per the Mayan Calendar b.s. on 12/21/2012, so I decided to take a drink with neighbors when I wrote up my original idea above (it can be done because of error handlers/exception handlers in C++ or Delphi though - they have them, above compiler structured error handling classes (C & PASCAL, again, don't)).

No, not *QUITE* drunk here, yet... lol, but close (3 hrs. to midnight, good chow @ neighbors is helping on that account... back to card game & brews now).

APK

P.S.=> Time to continue my drinking with my neighbors, we are having a good time/party there, & I have to bring the last case of beer I have over (it's pretty much "BYOB", but tons of good food too)... have a happy new year!

... apk

Re:Theoretical way to get size of C string (1)

JonySuede (1908576) | about a year and a half ago | (#42439215)

Where are my mod points now that your posts are on topic....

Re:C strings strike again! (1)

Anonymous Coward | about a year and a half ago | (#42437749)

This is the problem you get when your strings don't know their allocated size like in that ghastly language Pascal.

I would have to say that is an outright falsehood and misunderstanding of the language.

This is the problem you get when the programmer makes a serious error, who is the one and ONLY one who should be keeping track of the size of strings.

The entire C language is based around the idea that the programmer knows best. That's why it doesn't do unneeded things for you a bunch of times for each call.
So of course when the programmer does something stupid like not keep track of the size of strings, and pass what the docs out right claim is an invalid parameter, then stupid things like this result.
The language not only did nothing wrong, but did exactly what it claims it would do if you screw up and pass invalid arguments such as null when only a string pointer is valid.

If you are a programmer that doesn't know and doesn't want to know what you're doing, don't use C. There are plenty of other languages that will treat you that way, which you should be using instead.

Re:C strings strike again! (1)

BitZtream (692029) | about a year and a half ago | (#42437805)

Yea, adding unneeded checks to every operation because of lazy/shitty programmers is a much better idea.

Guess what, exploits happen in languages with managed arrays too!

Languages can't fix shitty programmers or mistakes, deal with it and stop blaming the language.

Re:C strings strike again! (1)

Rockoon (1252108) | about a year and a half ago | (#42437997)

Yea, adding unneeded checks to every operation because of lazy/shitty programmers is a much better idea.

I think the point that you are missing is that those checks are needed because the majority of programmers are both lazy and shitty once they are dealing with a large codebase. Here we have an obscure input causing the problem because its not obvious (lazy, shitty) that a variable might be null.

Re:C strings strike again! (1)

Sulphur (1548251) | about a year and a half ago | (#42438895)

This is the problem you get when your strings don't know their allocated size like in that ghastly language Pascal.

At least in the case of Turbo Pascal, there is an allocated size and an actual size (length) for string variables.

Re:C strings strike again! (1)

hedleyroos (817147) | about a year and a half ago | (#42439777)

Pascal is still a great language to learn how to code. I will never knock it.

EFnet is already paralyzed (1)

Plombo (1914028) | about a year and a half ago | (#42437169)

Who needs security vulnerability when you have a complete lack of services and modern IRC features?

Re:EFnet is already paralyzed (4, Interesting)

jones_supa (887896) | about a year and a half ago | (#42437219)

I wonder if the whole ancient IRC standard needs a steamrolling anyway. A lot of the new services are implemented by ugly hacks, bubblegum or bots. Things like registering a nickname, maintaining the administrators of a channel or handling netsplits, these could all be handled much more nicely. IRC needs a redesign from scratch...

Re:EFnet is already paralyzed (0)

Anonymous Coward | about a year and a half ago | (#42437247)

Yeah, and we could move it to the web, too! It needs a catchy name though... maybe something like Twitter?

Re:EFnet is already paralyzed (2, Funny)

Anonymous Coward | about a year and a half ago | (#42437319)

Google wave?

Re:EFnet is already paralyzed (1)

Anonymous Coward | about a year and a half ago | (#42437493)

Can we shorten the amount of text to about 40 or 20 characters? Better artificial limits can improve the quality of our chat content. Besides, it can help us achieve web-scale!

Re:EFnet is already paralyzed (3, Informative)

nenolod (546272) | about a year and a half ago | (#42437279)

There has been a lot of work in this area with a few projects now... Microsoft's IRCX, then IRCNEXT, IRCPLUS and now atheme.org's IRCv3 [ircv3.org] . IRCv3 is becoming the defacto standard at this point, supplanting the traditional IRC protocol, as almost all vendors that are noteworthy have adopted support for revision 3.1 of the protocol already.

Both Atheme and Anope can be interacted with via RPC from scripts allowing for web integrations. Also, there are immersive web clients which provide a lot of useful metadata to clients.

Re:EFnet is already paralyzed (4, Interesting)

IllusionalForce (1830532) | about a year and a half ago | (#42439741)

"Anope can be interacted with via RPC"... Yes, Anope 1.9. That's the development release, though. As much as I'd like to share your idealized view of IRC becoming a better place (except for the fact that I definitely wouldn't want to create an IRCd from scratch these days -- linking protocol and especially these goddamn CAP negotiations are just as bad as doing SSL from scratch. Who had the idea of message intents anyway?), fact is that the majority of networks that use Anope (and there are, due to the fact that quite a number of admins believe that levels are easier/better in some way or that Atheme is too much work to set up) use the stable 1.8 version.

Unlike the 1.7 dev version, 1.9 has not been widely adopted. This is mainly due to the fact that Anope 1.8 does just nearly enough out of the box to be still considered modern services, it's more hackable due to being coded in C (writing a module in 1.8 is definitely easier than in the C++ using 1.9 version. It's also easier to make it a complete fucking hackjob in 1.8) and has a bigger modding community (see http://modules.anope.org/ [anope.org] for pretty simple proof of that).

Additionally, it's still a mystery to me how IRCv3 works as an organization. It's described as a "meritocracy", but who is calling the shots in the end? You, nenolod? If so, then I'm not sure if the description shouldn't be rather "oligocracy" but that's pretty bad for the image of anything these days.

Furthermore, I would like to point out that, while four major IRCds are part of IRCv3/implement it, a big part of the implementations (especially so in UnrealIRCd) have actually come from people in the working group (namely you). While that in and of itself can hardly be considered a bad thing, it does lower the bus factor for future changes to the protocol to... precisely 1.

I do, however, agree with your belief that IRC needs a change, but I believe this is heading in the wrong direction. This is just cleaning the protocol up a bit. What we actually need are radical changes, which you'd need to discard all the old diehard IRC brigade for. Analyze what is currently popular: Xat, Facebook, IMs. Observe how two of those are web-based. Does IRC have a web-based client? Yes, it does. Mibbit, qwebirc and KiwiIRC (as well as IRCCloud, but they are absolutely uncooperative with any network). Mibbit sucks downright and is missing the oh-so-important colors to today's generation for the most part. qwebirc is tied to a network each. While that might simplify the handing on the user's part (one website for one network), it still sucks as a client (same color issue as Mibbit, even) and the entire concept of a network just rapes the minds of users. Users today don't know and they do not WANT to know that there are multiple IRC networks. They just want a chat room. Centralization is key. You can't talk of "a Xat chat" or "the Facebook chat" or "ICQ" or "MSN (Messenger)" in the same way you talk about IRC because the decentralized nature is included in none of them (though, if Jabber had found broader adoption amongst non-techies, which will not happen because of this precise very same argument, that would be a basis to work off). KiwiIRC looks promising, but no network has webirc blocks for them yet. Facebook wins because everybody else is already there, not because their chat technology (or anything else for that matter) is particularly innovative or good. Speaking of centralization, having multiple clients and networks is just even more confusion for new users. There is no "the IRC client" and there is no "the IRC network". That is not what users want. Janus links are a step in the right direction (as ugly as they may be), but not a solution.

On the topic of webirc blocks, banning people on IRC is an ordeal. It is a brutal pain in the neck. Other systems may require and enforce registration, so banning is very easy: Right click -> Ban. Or at least they abstract the banning itself away in some manner. You can't do that on IRC. You'll first spend some time telling people about things that should have long since ceased to exist: idents and hosts (and of course, reverse-resolving IP addresses. You can't tell me anyone is familiar with that from the get-go) and then the nick!ident@host format. This is just overly complex.

Another issue IRC is suffering from: Terminology. Oh, so much terminology and so much of it deprecated today. Channels? Chat rooms. Nick(name)s? User names (but that doesn't work because some IRC networks use user names for identification on their services. The lack of services on some places is even more confusing, not to mention that all services work differently in some subtle ways, as if to just confuse the user). Hostmask? Hostmasking?! Cloaking? vHosts? Channel and user modes? Channel and user settings!
Then there is always confusion about the word "network". Users believe there's always only one server. That's just silly, though, but can't be helped because that is how games and other things function quite often. Then we have the universally accepted terms of "administrator" and "moderator", possibly "owner" as well. What does IRC have? Owner (but not enabled by default on all networks, see Rizon, or possibly non-existent because the server admins/the IRCd coders don't want to support it), which should not be confused with founder status on services though, administrator/protected (which has two names to begin with and is also not to be expected/enabled by default on all networks), operator (can we just call it moderator, please?), half operator (Call it assistant moderator or something?) and voice (...No, this has no place in a modern terminology. Throw that out.). Not to mention that the symbols for these aren't the same everywhere, but only a minor case: Networks without owner use ! for admin as the prefix, other networks use & if owner is given. These prefixes are another problem, though. They're abstract. While IRC clients try to have some happy and shiny symbols, they are not the same everywhere, being the bane of any helper on IRC.

And what's with this talk about SSL or SSL certificate fingerprint auth? Way to confuse users even more. SSL should just become either standard or be discarded entirely as per http://www.quakenet.org/articles/99-trust-is-not-transitive-or-why-irc-over-ssl-is-pointless [quakenet.org] .

So, in essence, you are working on a nice thing, except you aren't solving any of the actual issues why IRC hasn't been able to grow.

Re:EFnet is already paralyzed (5, Funny)

Vermyndax (126974) | about a year and a half ago | (#42437321)

While you're at it, please redesign SMTP.

Re:EFnet is already paralyzed (2)

mysidia (191772) | about a year and a half ago | (#42437469)

IRC needs a redesign from scratch...

Sounds like a great idea... I even have an idea of what we could call the redesign: Jabber / Conference Room.

Re:EFnet is already paralyzed (1)

nenolod (546272) | about a year and a half ago | (#42437477)

MUC is extremely inefficient though. There is no multicast notion in XMPP, so MUC works around this by sending duplicate messages to each user directly.

Re:EFnet is already paralyzed (2)

mysidia (191772) | about a year and a half ago | (#42438033)

Jabber + PSYC [about.psyc.eu]

Re:EFnet is already paralyzed (1)

nenolod (546272) | about a year and a half ago | (#42438467)

PSYC suffers the same issue as MUC.

Re:EFnet is already paralyzed (2)

Anrego (830717) | about a year and a half ago | (#42437739)

Yeah, but redesigning something that has been around forever is hard (see: IPv4). Way too much legacy stuff out there dependant on the messed up way IRC works.

That said, gradual introduction of saner behavior is possible (see: Atheme/IRCv3).

If you build something from scratch you'll just end up with a potentially technically improved (or just broken in different ways) but largely ignored solution (and for this, see: jabber conference!)

Re:EFnet is already paralyzed (0)

Anonymous Coward | about a year and a half ago | (#42439457)

Retroshare is the wave of the future. irc is a dying service.

Re:EFnet is already paralyzed (0)

Anonymous Coward | about a year and a half ago | (#42439543)

Redesigning IRC is actually a hard problem.

An IRC network is essentially a distributed database and clients are applications connecting to that distributed database and submit a message to the database server to have a message relayed to another client, update the database or query the database's state.

So now that I've outlined the base problem to solve, come up with a database design that allows for 100 different database servers scattered around the globe to maintain a coherent global view. As a hint to the difficulty, most distributed databases exist in a cluster where transactional delays are minimal thanks to transports such as Infiniband (and a distributed database is not a trivial piece of technology in itself.)

The services such as nickname registration and channel administration are deliberately add-on services.

Re:EFnet is already paralyzed (1)

Gaygirlie (1657131) | about a year and a half ago | (#42437297)

Who needs security vulnerability when you have a complete lack of services and modern IRC features?

Lack of services and IRC-features? Like what?

Re:EFnet is already paralyzed (1)

nenolod (546272) | about a year and a half ago | (#42437309)

EFnet does not provide NickServ or ChanServ, which is a common criticism of the network. Due to not providing centralized authentication or channel ownership services, the other aspects of the modern IRC protocol mostly do not apply.

Re:EFnet is already paralyzed (0)

Anonymous Coward | about a year and a half ago | (#42437371)

EFnet does not provide NickServ or ChanServ, which is a common criticism of the network.

It's also why some people use EFNet instead of other networks which do provide those services.

Re:EFnet is already paralyzed (1)

Bengie (1121981) | about a year and a half ago | (#42437427)

EFNet is where I used to get my warez and anime... that took forever on a 14.4k modem.

Re:EFnet is already paralyzed (0)

Anonymous Coward | about a year and a half ago | (#42438157)

EFnet does not provide NickServ or ChanServ, which is a common criticism of the network.

It's also why some people use EFNet instead of other networks which do provide those services.

There's channel services now; albeit a crappy, gelded system. ChanFix has been in place for a few years now.

Re:EFnet is already paralyzed (1)

Krakhan (784021) | about a year and a half ago | (#42438675)

Also when I checked there a year or so ago they still don't cloak the ip address on your hostmask like a lot of modern irc networks do now by default as well.

Full disclosure takes a hit (1)

Bizzeh (851225) | about a year and a half ago | (#42437175)

which projects are now going to close their doors to full disclosure? this was posted on the ircd's own bug reporting systems and was publicly visible. if it were not, and only the developers and higher level users (such as the nodes of efnet or freenode) should be able to see reports of this nature, this sort of attack may not have happened and the ircd's could have been silently patched without anyone knowing.

on the other hand, if you close your doors, you obviously have something that requires hiding, drawing more attention.

what will projects do next?

Re:Full disclosure takes a hit (2)

nenolod (546272) | about a year and a half ago | (#42437209)

you do not know what you are talking about. the actual bug was disclosed in the IRC channel for charybdis. there was no "bug report."

Re:Full disclosure takes a hit (3, Interesting)

Kaenneth (82978) | about a year and a half ago | (#42437553)

Disclosed how? by example?

Sounds like when I found that if you put %s in a CounterStrike player name, the client would crash when showing the scoreboard, I tried %s after I noticed "%dxxxxxxx%" became "32401xxxxxxx%".

I reported it to Valve as soon as I figured out what it was, but it was a fun few days until they fixed it, "Hey look at that guys name!", server empties as people hit tab to show the scoreboard. I was server admin anyway, but it still was fun.

Re:Full disclosure takes a hit (0)

Anonymous Coward | about a year and a half ago | (#42437787)

what are you doing to trigger the crash
  socket.write("CAPAB \r\n"); ...wow

Re:Full disclosure takes a hit (1)

Anonymous Coward | about a year and a half ago | (#42437235)

You cannot "close your doors" to full disclosure, that doesn't make any sense. If someone wants to publicly announce a problem, they will always be able to do that. If someone wants to privately bring something to the attention of devs, they can always do that too. You cannot force people to use a disclosure method that they don't want to use.

Re:Full disclosure takes a hit (1)

AndroSyn (89960) | about a year and a half ago | (#42437307)

I don't see any reason to hide from bugs like this, people make mistake, code suffers from bitrot, etc. It's sure as shit embarrassing when a mistake in your code ends up on /. though.

Re:Full disclosure takes a hit (1)

BitZtream (692029) | about a year and a half ago | (#42437851)

Because EFNet is more or less non-functional since it was publicly disclosed?

Because no thousands of people pretty much can't chat, because someone else like you was too short sided to understand that some actions have larger overall consequences?

Because its fucking stupid to tell the world how to break something until its been fixed and thats only left for fucking jackasses to do.

Re:Full disclosure takes a hit (1)

nenolod (546272) | about a year and a half ago | (#42438505)

He did not disclose it, the person who disclosed the vulnerability did so in a public space for development discussion on charybdis. Once it was out in the open, we quickly jumped into action to start mitigating it across all fronts including EFnet. The ratbox developers were notified at least an hour before the exploit was unleashed, with a patch to deploy and everything, so really we did everything we could possibly do to mitigate the possibility of fallout.

Once people started running the exploit on EFnet servers, there was not much we could do, other than get the ratbox devs and admins regrouped elsewhere to coordinate getting things patched. I would say that things mostly went down as well as could be expected given the situation...

Re:Full disclosure takes a hit (1)

BitZtream (692029) | about a year and a half ago | (#42439551)

1 hour? Give me a fucking break. Doing it in public is as good as launching the attack yourself.

The patch could have been discussed behind closed doors. If you wanted to get someones attention about the real threat, you could have popped a single server ONCE without making it public.

Do you have any idea what its like running a network like EFNet and coordinating upgrades across all servers? Do you think there are admins awake and ready to be your bitch and patch their servers on your command in all time zones? Currently showing 44 servers linked ... Yea, an hour was plenty of time to deal with the issue ...

You're a douche for even saying what you're saying.

Great! (4, Funny)

lemur3 (997863) | about a year and a half ago | (#42437261)

Now I can finally get that nickname I have been wanting since 1999 !!

Re:Great! (1)

oursland (1898514) | about a year and a half ago | (#42439463)

That really dirty one? You know, THAT one!

the cause was bitrot... (2)

AndroSyn (89960) | about a year and a half ago | (#42437285)

This is a good case of bitrot here, code that had made assumptions about what the other parts of the code were doing..and fail. Brown paper bag day for me on EFnet :P

Re:the cause was bitrot... (0)

Mashiki (184564) | about a year and a half ago | (#42438085)

Hey now, I'd call it closer to a flaming brown paper bag day, filled with dog crap.

Well, one bad programmer learned a lesson (0)

Anonymous Coward | about a year and a half ago | (#42437291)

Validate your fucking inputs, you moron.

Re:Well, one bad programmer learned a lesson (0)

Anonymous Coward | about a year and a half ago | (#42437335)

Posts like this make me miss the efnet atmosphere in a Stockholm Syndrome kind of way.

Re:Well, one bad programmer learned a lesson (1)

PlusFiveTroll (754249) | about a year and a half ago | (#42438545)

Validate your fucking inputs, you moron.

That's the short version, the full version is

Validate all possible valid combinations of inputs are valid in all subroutines.

Huh... really? (0)

Anonymous Coward | about a year and a half ago | (#42437313)

People still use IRC?

Fuck that place got stupid when the aol generation showed up. I can't imagine how bad it is now this many years later.
Er... Well... From this story. yes. yes i can. Full on 'this is why we can't have nice things' mode.

Glad i don't go there anymore.

Re:Huh... really? (0)

Anonymous Coward | about a year and a half ago | (#42437359)

People still use IRC?

Fuck that place got stupid when the aol generation showed up. I can't imagine how bad it is now this many years later. Er... Well... From this story. yes. yes i can. Full on 'this is why we can't have nice things' mode.

Glad i don't go there anymore.

Actually most of the aol morons moved on to other places, like facebook, so there's not as many idiots as there used to be back in the 90's. And yes, people still do use IRC.

Re:Huh... really? (1)

aztracker1 (702135) | about a year and a half ago | (#42437545)

I haven't used efnet much in years... but am pretty active in a few channels on freenode.. Most active development platforms/projects have freenode channels these days.

Re:Huh... really? (0)

Anonymous Coward | about a year and a half ago | (#42438683)

Yep, I am on quite a few Freenode channels as well. Also, in Finland IRCnet is quite popular among the tech crowd, and outside as well. (and at least on my tech university every IT student at least gets introduced to it, and most are active there, via screen sessions running irssi on the school servers - also most IT courses have their IRC channels).

Stop writing things in C/C++ (0, Flamebait)

Anonymous Coward | about a year and a half ago | (#42437439)

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:Stop writing things in C/C++ (1)

nenolod (546272) | about a year and a half ago | (#42437509)

The problem isn't performance as much as it is accessibility. Almost every UNIX system has a C/C++ toolchain installed, not so much with Lisp, Java or C#. Also, C and C++ are generally the lowest common denominator for contributors. Almost everyone knows a little bit about C, not so many people know about Lisp (which is a travesty in and of itself, but not my problem).

Re:Stop writing things in C/C++ (2)

countach74 (2484150) | about a year and a half ago | (#42437557)

Throwing C++ into the same category as C is a bit retarded, is it not?

Re:Stop writing things in C/C++ (1)

Anonymous Coward | about a year and a half ago | (#42437641)

Throwing C++ into the same category as C is a bit retarded, is it not?

It's a lot retarded. But that never stopped anyone before.

Re:Stop writing things in C/C++ (0)

Anonymous Coward | about a year and a half ago | (#42438445)

Throwing C++ into the same category as C is a bit retarded, is it not?

Yes, it is. It fascinates the crap out of me that anyone still bothers with C, considering how much better C++ is.

Re:Stop writing things in C/C++ (2)

mark-t (151149) | about a year and a half ago | (#42438669)

What language would you advocate, exactly?

The *EXACT* same problem (abrupt program termination) would have plagued the software if had been written in either C# or Java unless exception-handling code was in place to prevent it. Not so coincidentally, the effort spent writing such exception handling code in C# or Java could just as easily be spent on a simple null pointer check before passing a value to strlen in C. Not to mention the fact that neither C# nor Java even existed when ircd was invented.

This was a flaw that exploited nothing more technical than programmer oversight, which can happen just as easily in software written in *ANY* language.

Re:Stop writing things in C/C++ (1)

cstacy (534252) | about a year and a half ago | (#42438707)

What language would you advocate, exactly?

Lisp

Re:Stop writing things in C/C++ (1)

mark-t (151149) | about a year and a half ago | (#42438789)

Interesting call... Lisp existed back then.

Granted, this particular crash would not have occurred had it been written in Lisp, but the failure on the part of the programmers to anticipate the kind of input that might produce a crash in C could just as likely to cause catastrophic failure in a program written in any language, even Lisp. Ultimately, the problem was not programming language choice - which is my whole point.

Re:Stop writing things in C/C++ (-1)

Anonymous Coward | about a year and a half ago | (#42438879)

Haskell. The Maybe Monad makes this mistake impossible.

Re:Stop writing things in C/C++ (1)

mark-t (151149) | about a year and a half ago | (#42439127)

Haskell didn't exist in 1992 either.

Re:Stop writing things in C/C++ (2)

JonySuede (1908576) | about a year and a half ago | (#42439255)

only if you use it ,pretty much like a null ceack or a try catch;

Rename idea (1)

93 Escort Wagon (326346) | about a year and a half ago | (#42437757)

They should change the name from EFnet to EFFYOUnet.

Submitter not that anonymous... (0)

Anonymous Coward | about a year and a half ago | (#42438265)

When the link to twitter has them posting via their twitter handle that they "anonymously" submitted the story/link on Slashdot...

Assigned CVE-2012-6084 for this issue (2)

seifried (12921) | about a year and a half ago | (#42439567)

As per http://www.openwall.com/lists/oss-security/2013/01/01/3 [openwall.com] this issue was assigned CVE-2012-6084. Remember folks, you can get your CVEs in advance which makes life easier for everyone. Please see http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html [redhat.com] for details.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...