EFnet Paralyzed By Vulnerability

← Back to Stories (view on slashdot.org)

EFnet Paralyzed By Vulnerability

Posted by Unknown on Monday December 31, 2012 @11:15AM from the blame-c dept.

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.

101 of 156 comments (clear)

Min score:

Reason:

Sort:

Sigh... by MightyMartian · 2012-12-31 11:18 · Score: 5, Funny

1998 called and want their attack vector back.

--
The world's burning. Moped Jesus spotted on I50. Details at 11.
1. Re:Sigh... by skovnymfe · 2012-12-31 11:20 · Score: 4, Funny
  
  It's retro cracking. Old is the new new, y'know?
2. Re:Sigh... by faedle · 2012-12-31 12:08 · Score: 2
  
  A 1998 attack vector for a 1992 network.
3. Re:Sigh... by NotQuiteReal · 2012-12-31 13:46 · Score: 1
  
  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!
  
  --
  This issue is a bit more complicated than you think.
4. Re:Sigh... by waspleg · 2012-12-31 14:00 · Score: 2
  
  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.
5. Re:Sigh... by petermgreen · 2013-01-01 02:41 · Score: 1
  
  Yeah, he screwed up his example, i'm pretty sure it would compile if he set s to null explicitly.
  Despite his mistake though his point stands, the problem of you (or a library you use) using null to represent "not known", "not present", "not found" or whatever and then passing the variable to a routine that assumes it will not be null impacts many languages that are far more "modern" than C.
  
  --
  note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
6. Re:Sigh... by pod · 2013-01-01 07:14 · Score: 1
  
  blammo - you should have checked if s was null first... Oh, and use that fancy try/catch stuff, all the cool kids do!
  The solution is *obvious* (duh), but the problem is not. You can't be putting an exception handler around every function call.
  What most likely happened, is by the time the string got to the strlen function, it was either assumed to have been security checked and data validated, or, the set of validations run was not complete.
  Shit happens.
  
  --
  "Hot lesbian witches! It's fucking genius!"
7. Re:Sigh... by Hentes · 2013-01-01 10:34 · Score: 1
  
  The difference is, you can't catch a segfault in C++.
8. Re:Sigh... by WhatAreYouDoingHere · 2013-01-01 11:42 · Score: 1
  
  1998 Called?!! Did you WARN them???!
  
  --
  "What are you doing here, Elijah?"
C strings strike again! by cheesybagel · 2012-12-31 11:21 · Score: 3, Insightful

This is the problem you get when your strings don't know their allocated size like in that ghastly language Pascal.
1. Re:C strings strike again! by cheesybagel · 2012-12-31 11:22 · Score: 2, Insightful
  
  Not to mention the whole C issue where pointers to something and arrays of something are sort of the same but not really.
2. Re:C strings strike again! by ls671 · 2012-12-31 11:34 · Score: 2, Informative
  
  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
  
  --
  Everything I write is lies, read between the lines.
3. Re:C strings strike again! by nenolod · 2012-12-31 11:45 · Score: 1, Interesting
  
  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, 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.
4. Re:C strings strike again! by cheekyboy · 2012-12-31 12:48 · Score: 1
  
  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.
  
  --
  Liberty freedom are no1, not dicks in suits.
5. Re:C strings strike again! by Anonymous Coward · 2012-12-31 12:56 · Score: 1
  
  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.
6. Re:C strings strike again! by Lunix+Nutcase · 2012-12-31 12:58 · Score: 3, Informative
  
  Pitty intel didnt implement string functions in the CPU.
  They did. Welcome to decades ago.
7. Re:C strings strike again! by BitZtream · 2012-12-31 13:03 · Score: 1
  
  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.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
8. Re:C strings strike again! by Teckla · 2012-12-31 13:03 · Score: 1
  
  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.
9. Re:C strings strike again! by Rockoon · 2012-12-31 13:26 · Score: 1
  
  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.
  
  --
  "His name was James Damore."
10. Re:C strings strike again! by VGPowerlord · 2012-12-31 14:08 · Score: 2
  
  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.
  
  --
  GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
11. Re:C strings strike again! by the+eric+conspiracy · 2012-12-31 14:37 · Score: 1
  
  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.
12. Re:C strings strike again! by nedlohs · 2012-12-31 16:29 · Score: 2
  
  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.
13. Re:C strings strike again! by muridae · 2012-12-31 16:33 · Score: 1
  
  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?
14. Re:C strings strike again! by Sulphur · 2012-12-31 16:34 · Score: 1
  
  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.
15. Re:C strings strike again! by oursland · 2012-12-31 18:45 · Score: 1
  
  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!!!
16. Re:C strings strike again! by hedleyroos · 2012-12-31 20:13 · Score: 1
  
  Pascal is still a great language to learn how to code. I will never knock it.
17. Re:C strings strike again! by TheRaven64 · 2012-12-31 20:52 · Score: 1
  
  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.
  
  --
  I am TheRaven on Soylent News
18. Re:C strings strike again! by TheRaven64 · 2012-12-31 20:55 · Score: 2
  
  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.
  
  --
  I am TheRaven on Soylent News
19. Re:C strings strike again! by TheRaven64 · 2012-12-31 20:57 · Score: 2
  
  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.
  
  --
  I am TheRaven on Soylent News
20. Re:C strings strike again! by voidphoenix · 2012-12-31 22:19 · Score: 1
  
  1978! That's so last millenium!
  
  --
  Excuse me, wtf r u doin?
21. Re:C strings strike again! by ThePhilips · 2013-01-01 01:45 · Score: 1
  
  especially in servers where robustness is important.
  Ditto for C/C++ applications "where robustness is important". Implementation looks different, but same in the essence.
  Some memory debuggers and code analyzers (Insure for example) can even catch the error during compilation (IIRC so called "wild pointers" in the Insure speak).
  Experience we made with HA software, null pointer problems are (often but only) nasty in C/C++ and are horrible in Java. Some stats. As new release went into tests/production, we found in total about 200 *crashes* due to null pointers in C/C++ apps. In Java part (about half the size of the C/C++) there were about 20 null pointer exceptions - with one which was occurring only in the production. This sole exception cost about 6 month of work to localize - because unlike core dump, Java's stack trace (due to your "which is often the case") was already unwound and couldn't point to the location of the show-stopper problem. This particular case (and it's not a sole Java debacle) became famous, because CTO of the customer, during a meeting, exclaimed that he wished the software was written in C instead, so that developers can see from core dump where the problem is.
  What I'm getting here to. If robustness is expected from the software, to customer, it doesn't matter how it fails - crashes or denies service - what matters is that the problem can be quickly localized and fixed. Trivial problems like missing null pointer check in C can be localized from core dump within seconds. Trivial problems like missing null pointer check in Java occasionally cause high level fsckups, thanks to the blank exception handling one often has to resort to. So from practical point of view, the languages unfortunately are very close.
  
  --
  All hope abandon ye who enter here.
22. Re:C strings strike again! by ThePhilips · 2013-01-01 01:58 · Score: 1
  
  The main thing is that we need a language which provides scalable data structures, as servicing IRC messages involves many data lookups.
  Are you CTO per chance? VP of tech? You talk like one.
  But if you want it to be addressed in a programming language.
  Until language developers suck it up and start making languages that allow for opposite concepts in the same language, it would remain the same.
  For example.
  Most stupid errors in strict typed languages are in the code for some type weakness - because, duh, strictly typed languages provide zero standard facilities to implement weak typing when you need it. So you have to roll out your own.
  Most stupid errors in weak-typed languages are related to wrong intermixing of types - because, duh, weakly typed languages provide zero standard facilities to implement strict typing when you need it. So you have to roll out your own.
  And it goes on.
  
  --
  All hope abandon ye who enter here.
23. Re:C strings strike again! by nedlohs · 2013-01-01 02:50 · Score: 2
  
  0 would be terrible, since it isn't a zero length string and that's lying to the caller. Crashing is a better option, at least you stop the damage there and then rather than the program generating garbage output. An exception is better still, but C doesn't have those - segfaulting sort of works as one if you squint.
  -1 isn't an option because the return value is a size_t which is unsigned.
  Sure it's far from an ideal setup, but C is language built on a philosophy that the compiler and libc should be relatively simple to implement. And if that complicates programs written in C then that's the trade off that was chosen - there are other languages that made the opposite trade off.
24. Re:C strings strike again! by fatphil · 2013-01-01 03:24 · Score: 1
  
  -1? *snigger*.
  
  And strcmp compares strings. NULL does not point to a string, therefore you shouldn't expect string functions to work.
  
  C expects the programmer to know what he's doing, that's all.
  
  --
  Also FatPhil on SoylentNews, id 863
25. Re:C strings strike again! by Teckla · 2013-01-01 05:16 · Score: 1
  
  Experience we made with HA software, null pointer problems are (often but only) nasty in C/C++ and are horrible in Java. Some stats. As new release went into tests/production, we found in total about 200 *crashes* due to null pointers in C/C++ apps. In Java part (about half the size of the C/C++) there were about 20 null pointer exceptions - with one which was occurring only in the production. This sole exception cost about 6 month of work to localize - because unlike core dump, Java's stack trace (due to your "which is often the case") was already unwound and couldn't point to the location of the show-stopper problem. This particular case (and it's not a sole Java debacle) became famous, because CTO of the customer, during a meeting, exclaimed that he wished the software was written in C instead, so that developers can see from core dump where the problem is.
  That's interesting. My experience has actually been the opposite. I spent a few decades programming in C, and about a decade ago switched to Java.
  In my experience -- which is, of course, just anecdotal -- C presented more difficulties. Core dumps are useful, of course, but it meant the entire process -- including all the threads -- went down. For high reliability requirements, we typically used a watcher daemon to restart processes that crashed unexpectedly.
  In Java, unless you go out of your way to catch NullPointerExceptions and then purposefully eat the attached stack trace, you should know precisely where and why it happened. In addition, it should just kill the one thread. Though typically, we'd wrap threads with catch-all-log-all-and-restart-thread logic, which is just a few lines of code.
  However, I'm not recommending Java over C, or vice-versa, though. I consider the application domains where C and Java compete to be pretty small these days, so typically I consider the correct choice to be dictated by the application domain.
26. Re:C strings strike again! by ThePhilips · 2013-01-01 07:13 · Score: 1
  
  Core dumps are useful, of course, but it meant the entire process -- including all the threads -- went down. For high reliability requirements, we typically used a watcher daemon to restart processes that crashed unexpectedly.
  We allow to start several instances of the same process: if one goes down, others are still there.
  
  However, I'm not recommending Java over C, or vice-versa, though. I consider the application domains where C and Java compete to be pretty small these days, so typically I consider the correct choice to be dictated by the application domain.
  In all fairness, I'm not a specialist in Java. Probably your experience is more relevant than mine.
  But I have seen already enough of spaghetti Java code to stop believing entirely the fairy tail of "better language will solve all problems."
  
  In Java, unless you go out of your way to catch NullPointerExceptions and then purposefully eat the attached stack trace, you should know precisely where and why it happened.
  Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the innards of the library.
  Overall, I think the issue of crashes/etc of C programs is overblown. I have checked my historical TODO lists and lion share of stuff are complains that stuff doesn't work as expected. For the whole year 2012 I had only 2 core dump issues out of around 100 tickets which I had to process. Largest feature I did this year had problems with dead-locks in multi-threaded mode, but not a single crash.
  
  --
  All hope abandon ye who enter here.
27. Re:C strings strike again! by Teckla · 2013-01-01 07:54 · Score: 1
  
  But I have seen already enough of spaghetti Java code to stop believing entirely the fairy tail of "better language will solve all problems."
  Easier/safer languages are a double edged sword. In the hands of a master, it makes the master that much more productive, because they're not wasting wetware cycles on details like "will concatenating this string overflow my destination buffer?". But, at the same time, it makes programming more accessible to people who really shouldn't be doing software development.
  I like to think I'm a good software developer and that using Java makes me more productive, but I readily admit that your average C developer is probably more talented than your average Java developer, possibly by a wide margin.
  
  Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the innards of the library.
  This used to be a more serious problem, but fortunately, these days you can wrap an exception in a new exception and not lose the underlying stack trace. It's the common idiom now. For example: catch (IOException e) { throw new MyLibraryException(e); }
  
  Overall, I think the issue of crashes/etc of C programs is overblown. I have checked my historical TODO lists and lion share of stuff are complains that stuff doesn't work as expected. For the whole year 2012 I had only 2 core dump issues out of around 100 tickets which I had to process. Largest feature I did this year had problems with dead-locks in multi-threaded mode, but not a single crash.
  I believe it. I wonder if it's because all the less talented programmers have moved onto easier/safer languages, as I suggested above. In fact, that's one of my pet theories why your average iOS application is better than your average Android application. It takes a certain determination and skill to master Objective-C, while Java is a lot more "accessible" to less talented developers.
  In many ways, I very much miss doing regular C development, though I do wish they would have added a few language features that I consider "must have" for modern development these days, such as "real strings" -- but that opens a whole other can of worms. :-)
28. Re:C strings strike again! by ThePhilips · 2013-01-01 08:25 · Score: 1
  
  [...] In the hands of a master, it makes the master that much more productive, because they're not wasting wetware cycles on details like "will concatenating this string overflow my destination buffer?".
  Bad example.
  A good sign of a non-master is attempt at concatenating string. Think of it, even Java *cannot* concatenate strings. :)
  Contemporary C master wouldn't even think about it. Far cry from StringBuilder, but all the functions for safe string handling are already there - one only has to use them. (Although some thought might go into defining the limits for the buffers.)
  
  Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the innards of the library.
  This used to be a more serious problem, but fortunately, these days you can wrap an exception in a new exception and not lose the underlying stack trace. It's the common idiom now. For example: catch (IOException e) { throw new MyLibraryException(e); }
  A link/name for the idiom I can pass to our Java people?
  
  --
  All hope abandon ye who enter here.
29. Re:C strings strike again! by Teckla · 2013-01-01 09:19 · Score: 1
  
  A link/name for the idiom I can pass to our Java people?
  I think I would just point them to the Java API documentation and point out these constructors for java.lang.Exception:
  Exception(String message, Throwable cause)
  Constructs a new exception with the specified detail message and cause.
  Exception(Throwable cause)
  Constructs a new exception with the specified cause and a detail message of (cause==null ? null : cause.toString()) (which typically contains the class and detail message of cause).
  These two additional constructors were added to Java 1.4 (so, a good long time ago) precisely because of the issue of catching and re-throwing exceptions and losing the underlying stack trace. These constructors solve that issue. (It does, however, make the stack trace that much longer, so it's pretty noisy!)
  All that being said, I'm not really a fan of exceptions. I like old fashioned return codes myself.
30. Re:C strings strike again! by MakerDusk · 2013-01-02 02:37 · Score: 1
  
  Are you CTO per chance? VP of tech? You talk like one.
  
  nenolod is the current head of the atheme project. He can be found on irc.staticbox.net #atheme. He's a good knowledgable guy (for the most part).
31. Re:C strings strike again! by g00ey · 2013-01-03 19:28 · Score: 1
  
  TheRaven64: A few years ago you wrote this:
  
  Possible, but nowhere near as easy. I've read most of volume 3A of Intel's architecture reference while doing background reading for my Xen book, but the complete architecture reference is well over 3,000 pages. The GPU reference - if you can get it - is a similar length, and that's before you get to the OS. The Design and Implementation of the FreeBSD Operating System is 720 pages. It's a good book, but it skips over a lot of details. The copy of the X11 protocol reference that I read was several hundred pages, and it's a few revisions old. The OpenGL reference was a similar length. But now you can do 2D and 3D graphics and, once you've read the C spec (not so bad, only a couple of hundred pages) and spent some time familiarising yourself with your C compiler and standard library you can draw things.
  
  To get the level of understanding that the original poster is talking about, on a modern computer, means reading and remembering around 10,000 pages of reference books, and gaining familiarity with the source code that they mention. And that's just going to give you one CPU architecture and the core bits of the OS.
  
  as a reply to a guy who basically said that a modern PC is essentially no more than a faster C64 with more memory and expandability options...
  
  Now, my question to you is; what would you say about the ARM platform and Arduino? Would you say that e.g. a Raspberry Pi system is as simple to program as a C64 or Amiga?
32. Re:C strings strike again! by TheRaven64 · 2013-01-03 23:34 · Score: 1
  
  Wow, that's a crazy tangent.
  I don't know much about the Arduino, but my understanding is that it's basically a microcontroller with the I/O pins wired to something that it's easy to connect stuff to. As such, the CPU is probably on the same order of complexity as a 6502, so about as easy to program, although the tools have improved a lot. It also doesn't have any of the coprocessors (e.g. for sound and video) that a C64-era machine typically had. Note, however, that I was talking about fully understanding the machine, not about programming it. One of the major developments in computing over the past couple of decades is that it is now easy to program computers while only having a very abstract idea of how they work.
  A modern ARM system, even an oldish one like the RPi (which, by the way, is designed two floors up from me) is vastly more complicated. In the middle of the RPi, there's an ARM11 CPU. This is pretty old by computing standards, but still fairly modern. It's about the only ARMv6 implementation still shipped (everything else is ARMv7, with ARMv8 just about to appear), and lacks the atomic operations and some of the nicer FPU support of the newer CPUs, but you still have a basic CPU design that supports multiple nested interrupt levels, virtual memory, write-through or write-back caching. The ARM ARM is a lot shorter than the IA32 manual, but it's still a pretty hefty book. By itself, it's longer than the manual that came with my BBC Model B, which included an explanation of the BASIC dialect, full descriptions of the video modes (including text and teletext modes), a complete description of the 6502 instruction set, and diagrams of the circuit boards. The RPi also has a fairly nice GPU, which is not even publicly documented, so good luck understanding how that works, and a few other coprocessors. The video output is DVI, which is a fairly complicated specification: quite understandable, but a lot more complex than the unmodulated analogue video out of TV-connected microcomputers from the '80s. You couldn't, for example, build a light pen for the RPi (even if you did connect it to a CRT), because the position of the photon beam is not exposed. You could for the BBC, and it was quite easy.
  And that's ignoring all of the other hardware on the RPi's SoC, such as the UARTs, programmable interrupt controller and the DMA engines, each of which is of the same order of complexity as a 6502.
  The main difference between ARM and x86 is ARM's willingness to phase out legacy cruft. The PC comes with a BIOS (or EFI that can emulate a BIOS), implementing the same set of BIOS interrupts (effectively system calls) that the original IBM PC implemented and all of the integrated peripherals that had analogs in the IBM PC support this interface (e.g. keyboard, mouse, text-based video console). It comes with a CPU that supports a protection model that is 100% backwards compatible with real-mode 16-bit code, and also with protected mode 32-bit code for the 80386. In contrast, an ARMv6 implementation can run any user-mode ARM code, but it won't boot an OS written for ARMv5 and will need new drivers for things like the console, display, USB, and so on (ARMv6 didn't even specify the interrupt controller. Neither does ARMv7, but the Cortex-A9 and newer all do).
  
  --
  I am TheRaven on Soylent News
EFnet is already paralyzed by Plombo · 2012-12-31 11:25 · Score: 1

Who needs security vulnerability when you have a complete lack of services and modern IRC features?
1. Re:EFnet is already paralyzed by jones_supa · 2012-12-31 11:33 · Score: 4, Interesting
  
  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...
2. Re:EFnet is already paralyzed by nenolod · 2012-12-31 11:41 · Score: 3, Informative
  
  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 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.
3. Re:EFnet is already paralyzed by ls671 · 2012-12-31 11:43 · Score: 1
  
  Well, I still like the distributed design of it so keep it please. See picture here:
  http://en.wikipedia.org/wiki/Internet_Relay_Chat#Client_software
  
  --
  Everything I write is lies, read between the lines.
4. Re:EFnet is already paralyzed by Gaygirlie · 2012-12-31 11:44 · Score: 1
  
  Who needs security vulnerability when you have a complete lack of services and modern IRC features?
  Lack of services and IRC-features? Like what?
5. Re:EFnet is already paralyzed by nenolod · 2012-12-31 11:47 · Score: 1
  
  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.
6. Re:EFnet is already paralyzed by Anonymous Coward · 2012-12-31 11:48 · Score: 2, Funny
  
  Google wave?
7. Re:EFnet is already paralyzed by Vermyndax · 2012-12-31 11:49 · Score: 5, Funny
  
  While you're at it, please redesign SMTP.
8. Re:EFnet is already paralyzed by Bengie · 2012-12-31 12:07 · Score: 1
  
  EFNet is where I used to get my warez and anime... that took forever on a 14.4k modem.
9. Re:EFnet is already paralyzed by mysidia · 2012-12-31 12:14 · Score: 2
  
  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.
10. Re:EFnet is already paralyzed by nenolod · 2012-12-31 12:16 · Score: 1
  
  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.
11. Re:EFnet is already paralyzed by Anonymous Coward · 2012-12-31 12:17 · Score: 1
  
  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!
12. Re:EFnet is already paralyzed by Anrego · 2012-12-31 12:54 · Score: 2
  
  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!)
13. Re:EFnet is already paralyzed by mysidia · 2012-12-31 13:33 · Score: 2
  
  Jabber + PSYC
14. Re:EFnet is already paralyzed by nenolod · 2012-12-31 14:48 · Score: 1
  
  PSYC suffers the same issue as MUC.
15. Re:EFnet is already paralyzed by Krakhan · 2012-12-31 15:33 · Score: 1
  
  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.
16. Re:EFnet is already paralyzed by IllusionalForce · 2012-12-31 20:07 · Score: 3, Interesting
  
  "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/ 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
17. Re:EFnet is already paralyzed by dkf · 2013-01-01 03:27 · Score: 1
  
  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.
  That's also pretty much how IRC works (though the message formatting is rather different). For real efficient multicast, you need to implement it at the network level so that messages are sent directly to the other listening parties by the hardware, but IP multicasting is complex and full of all sorts of "interesting" problems when you use it at larger scales than the LAN. Re-transmitting messages (even with updated IDs and other such info) is far simpler in practice. Really.
  
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
18. Re:EFnet is already paralyzed by someones · 2013-01-01 08:32 · Score: 1
  
  and HTTP.
Full disclosure takes a hit by Bizzeh · 2012-12-31 11:25 · Score: 1

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?

--
portfolio
1. Re:Full disclosure takes a hit by nenolod · 2012-12-31 11:32 · Score: 2
  
  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."
2. Re:Full disclosure takes a hit by Anonymous Coward · 2012-12-31 11:35 · Score: 1
  
  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.
3. Re:Full disclosure takes a hit by AndroSyn · 2012-12-31 11:46 · Score: 1
  
  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.
4. Re:Full disclosure takes a hit by Kaenneth · 2012-12-31 12:26 · Score: 3, Interesting
  
  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.
5. Re:Full disclosure takes a hit by BitZtream · 2012-12-31 13:07 · Score: 1
  
  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.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
6. Re:Full disclosure takes a hit by nenolod · 2012-12-31 14:55 · Score: 1
  
  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...
7. Re:Full disclosure takes a hit by BitZtream · 2012-12-31 19:08 · Score: 1
  
  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.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
8. Re:Full disclosure takes a hit by AndroSyn · 2013-01-01 03:38 · Score: 2
  
  1 hour? Give me a fucking break. Doing it in public is as good as launching the attack yourself.
  EFnet was fixed within an hour or two for the most part. More importantly the hub servers were not impacted which helped with getting things working sooner.
  
  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.
  Indeed the patch could have been discussed behind closed doors, but sometimes zero day things happen. The real question is how do you deal with it when it happens.
  
  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.
  I personally fixed 4 or 5 efnet servers directly and got patches out to the efnet admin community pretty quickly. Neonlod also had patches out pretty quickly as well, sooner than I did actually.
  TBH I'm surprised that it didn't happen sooner seeing that the bug had been there since 2004. The bug itself was a combination of errors. First was a code change that was supposed to do parameter count checking for the called function, however zero was put in for the parameter count that was required.
  This didn't matter for a while though as the rest of the code didn't rely on that parameter count checking code. However when some additional code was added, it wasn't protected by the old code that didn't care about parameter count, but it expected that the new parameter count code was working(which it wasn't) thus a command with an empty parameter caused the core dump. Fail.
Great! by lemur3 · 2012-12-31 11:38 · Score: 4, Funny

Now I can finally get that nickname I have been wanting since 1999 !!
1. Re:Great! by oursland · 2012-12-31 18:46 · Score: 1
  
  That really dirty one? You know, THAT one!
the cause was bitrot... by AndroSyn · 2012-12-31 11:42 · Score: 2

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
1. Re:the cause was bitrot... by AndroSyn · 2013-01-01 05:12 · Score: 1
  
  So it was you who left that on my doorstep this morning!!! :D
Theoretical way to get size of C string by Anonymous Coward · 2012-12-31 12:04 · Score: 2, Interesting

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
(@ 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
1. Re:Theoretical way to get size of C string by Anonymous Coward · 2012-12-31 12:11 · Score: 2, Funny
  
  Can these solutions be used in a Hosts file?
2. Re:Theoretical way to get size of C string by ls671 · 2012-12-31 12:42 · Score: 1
  
  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.
  
  --
  Everything I write is lies, read between the lines.
3. Re:Theoretical way to get size of C string by webmistressrachel · 2012-12-31 17:00 · Score: 1
  
  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.
  
  --
  This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
4. Re:Theoretical way to get size of C string by JonySuede · 2012-12-31 17:48 · Score: 1
  
  Where are my mod points now that your posts are on topic....
  
  --
  Jehovah be praised, Oracle was not selected
Re:Stop writing things in C/C++ by nenolod · 2012-12-31 12:19 · Score: 1

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:Huh... really? by aztracker1 · 2012-12-31 12:25 · Score: 1

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.

--
Michael J. Ryan - tracker1.info
Re:Stop writing things in C/C++ by countach74 · 2012-12-31 12:26 · Score: 2

Throwing C++ into the same category as C is a bit retarded, is it not?
Re:Stop writing things in C/C++ by Anonymous Coward · 2012-12-31 12:39 · Score: 1

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.
Rename idea by 93+Escort+Wagon · 2012-12-31 12:56 · Score: 1

They should change the name from EFnet to EFFYOUnet.

--
#DeleteChrome
Objective-C nil by tepples · 2012-12-31 13:57 · Score: 1

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.
1. Re:Objective-C nil by TyFoN · 2013-01-01 03:19 · Score: 1
  
  Ugh, this really sounds like the way SAS responds when you try to access a field that doesn't exist. It will just create it and initialize it to missing value.
  I'm sure the objc solution is creating a _lot_ more bugs than it "fixes".
2. Re:Objective-C nil by thePowerOfGrayskull · 2013-01-01 04:35 · Score: 1
  
  Ugh, seriously? Nothing like forced non-failure of software instead of a failure that could prevent more serious consequences...
3. Re:Objective-C nil by v1 · 2013-01-01 09:04 · Score: 1
  
  it's better to react to an error than try to ignore it. Though I think I'd prefer a log entry to a core dump. I prefer to write bulletproof code, and I frequently benefit from it. Just this morning in fact I got a warning email that a directory create failed on a script. It wasn't a shell crash, it was an authentic "assertion failed" routine of mine getting called to fire off an email, when an rm -d returned nonzero.
  It was something that "should never fail". ("so why bother testing the return code?") Unless someone (like um... me) changes a folder name up a few levels. (oops) But instead of a crash in flames, or a "why the heck isn't the script updating those files??" (half hour later, find "because it's ignoring an error") I get a warning, and I fix it. and all is well.
  
  --
  I work for the Department of Redundancy Department.
Re:Well, one bad programmer learned a lesson by PlusFiveTroll · 2012-12-31 15:04 · Score: 1

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.
Re:Stop writing things in C/C++ by mark-t · 2012-12-31 15:32 · Score: 2

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.

--
File under 'M' for 'Manic ranting'
Re:Stop writing things in C/C++ by cstacy · 2012-12-31 15:43 · Score: 1

What language would you advocate, exactly?
Lisp
Re:What the EF? by X0563511 · 2012-12-31 16:01 · Score: 1, Funny

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

--
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Re:Stop writing things in C/C++ by mark-t · 2012-12-31 16:05 · Score: 1

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.

--
File under 'M' for 'Manic ranting'
Re:Stop writing things in C/C++ by mark-t · 2012-12-31 17:30 · Score: 1

Haskell didn't exist in 1992 either.

--
File under 'M' for 'Manic ranting'
Re:Stop writing things in C/C++ by JonySuede · 2012-12-31 17:58 · Score: 2

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

--
Jehovah be praised, Oracle was not selected
Assigned CVE-2012-6084 for this issue by seifried · 2012-12-31 19:12 · Score: 2

As per http://www.openwall.com/lists/oss-security/2013/01/01/3 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 for details.
Re:Stop writing things in C/C++ by Kjella · 2013-01-01 08:18 · Score: 1

The major difference between exceptions and null checks is the granularity. You can for example have a try/catch around the whole function parser that will kick in on any sort of failure and just say "whoops, something bad happened parsing this command" and it won't really matter what part inside that failed as long as you can recover, in that case probably by just ignoring that command and keep running. With null checks you must have one in every possible place you might call a null pointer. Particularly for a server then it can often happen that this client session is borked because it triggered some kind of "impossible" exception, you have to kill it but unless the entire server state is borked you don't need to kill the whole server. It's actually one of the things I hate the most with C/C++, without exceptions then one error means the whole application goes boom.

--
Live today, because you never know what tomorrow brings
Re:Stop writing things in C/C++ by mark-t · 2013-01-01 12:54 · Score: 1

Only if simply ignoring errors and continuing in the program's main event loop is adequate. This can be the case with many programs, but can very easily cause side effects resulting from incomplete operations.

--
File under 'M' for 'Manic ranting'
Re:You're a known DIRTY tricks troll, scumbag... a by webmistressrachel · 2013-01-01 13:01 · Score: 1

"Screw you, apk, and the horse you rode in on. If I ever see you post here again, I'll bomb you as AC from Tor, meaning I'll NEVER run out of posts because I can change endpoint."
You know damn well I posted this in anger because you were accusing me of doing it anyway, and of being "Barbie". You, and anyone else who can read this, will notice that I posted with my UID and when I do post I don't post AC. I have posted embarassing stuff about myself IRL to prove this incorrect but instead you used this against me, making assumptions about my gender makeup and whether I am who I say I am.
I extended an olive branch, and you abused it by ranting at Barbie telling him/her she was me or vice versa. So who's the troll, apk??
Here, another olive branch to prove I'm not Barbie, go do a whois on www.rachelwilson.net.

--
This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
Re:No, I've got YOUR # down troll (& you KNOW by webmistressrachel · 2013-01-01 14:06 · Score: 1

Bullshit, most of that. You're so wordy, and you've got it so wrong. Fortunately, I have an IRL to go back to that encourages me to contribute positive change around me (unlike this place and people like you).
Thanks for ruining my evening after I simply told someone it was bad form to drag you down to that level after you posted something positive.

--
This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
Re:Evasion, another "classic troll FAIL" by webmistressrachel · 2013-01-01 15:54 · Score: 1

This all started because I completely disagreed about the use of HOSTs as compared to Adblock or similar, and you started personally insulting someone I know. Now, you're doing the same to me.
Defend myself, I'm a stalker. Ignore you, people might think you were correct. What a dilemma. You're one evil, uncaring guy, apk. Security tools = positive change? Try www.timberrecycling.org for positive change. Or www.manchester.gov.uk/elections. Or call Greater Manchester Police and ask them about Rachel Wilson. If they say they've never heard about me, mention Operation Protector, or Operation Foot. They've heard of those, and will be able to look up my details quick enough.
I find you ego-centric list of challenges disturbing. How, as you quite rightly point out, could I have the experience you have when you were born first, went to what seems like decent schools and colleges, and actually had friends and good teachers as a child? You have taken no time or care at all to ensure what you are saying is relevent to me at all. Why should I care? I know I'm a good person, and admitting to teasing you about HOSTS (Which everyone here does, because it's a PLAIN STUPID solution to a common problem!) does not make me a stalker at all.
In fact, I'd welcome any investigation into such because it would simply prove that I'm not Tomhudson, and that you are assuming you're talking to me when I'm not even there. I checked the link and parent, and no, that's not me.

--
This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen