Actually, in a long-running system (such as a network server), a garbage collector is an advantage, not a liability:
1. Memory leaks are not possible. 2. Heap compaction IS possible (the garbage collector can move around data rather like DOS defrag). That means that the heap loses its fragmented nature when necessary. It's true that a C program does less allocation, but the malloc model doesn't allow for the heap to be defragmented! So for a long running program, you are typically stuck with fragmented memory that can't be reused...
So I say garbage collected languages win on this point!
> I disagree. Hell, Mozilla was painfully slow on > 350 Mhz Pentium II until about 0.9.5 or so. That > doesn't mean it needed C, of course, but to ignore > performance is a bad idea.
Lots of Mozilla is written in Javascript, which is one of the main reasons it is such a resource hog. I think the performance would actually improve if it were written in pure SML.
Mozilla is a bad example, though, because people actually do complain about the speed of their web browser. (And buffer overflows are less serious here!) I really mean to just argue for network *servers*. You're right to call me on that, but for say, ftpd, I think the choice is clear.
The JVM is probably written in C. Java the language doesn't suffer from all of these problems, just particular implementations may. (There have been security exploits based on bugs in the JVM before, yes.)
When I say that a language is safe, I mean that the definition of the language doesn't permit "undefined behavior" (where in the case of a C buffer overflow, this leads to running of arbitrary code by an attacker). Java falls into this category. So does SML. Perl and Python do, too, though it is hard to say because they are only defined by their implementations. (So it is hard to separate the language from implementation.)
Perl and Python, because of their ability to execute commands on the system so easily or interpret code sent by an attacker, are subject to a different class of security holes. Because Perl (especially) attempts to make so much functionality available to the user, it often leads to hack-job scripts that are difficult to reason about. It is true, though, that these languages are "safe" in the sense that they don't permit crashes (that could lead to execution of machine code).
Why is it unfair to mention that perl has had oveflows? I merely want to challenge the notion that slashdot folks seem to have that buffer overflows are an easy thing to avoid, and that they're only made by "bad" programmers. How can you say that "apparently they're all gone now"?
Some safe languages (or, say, natively compiled Java) don't have virtual machines. As far as I know, it's difficult to have a bug in a compiler that leads to exploitable security holes. It is certainly possible, but would take a much stranger situation than the ones that typically cause buffer overflows in C programs! And of course, fixing the compiler would fix all of the programs written using it automatically. (Well, after recompiling.;)) Finally, C compilers also are subject to this "problem", so it has an equal disadvantage anyway.
As for source code, I'm pretty sure there are open source implementations of the JVM. I am not a big java fan, myself. Yes, I have the source to my SML compiler.
> Not to detract from your main point, which is a > good one and well made, but that particular > statement is pretty dubious.
OK, you're right. I guess I what I really meant to say is, "For the home user with a powerful computer and relatively small bandwidth, CPU performance of network applications is nowhere near as important as security is."
I still think SML or O'Caml could take off with hakers, but I'm still trying to figure out a way to convince them to try something new. It's really not that hard, and the interfaces to system libraries are actually rather straightforward.
In fact, it was very easy -- it took me about a weekend to get it working, and then a few days of tinkering to polish it off. That included writing an MD5 crypt library, and mechanisms for writing network daemons that I intend to re-use for later projects.
I don't know why it is, but there is this sort of gut reaction that the slashdot crowd has about this kind of stuff (maybe it comes from UNIX's history). Since it's not written in C, it is seen as somehow inferior. Even though it supports 99% of the RFC (I would finish it off if people cared..), is 100% buffer-overflow free, much shorter and elegant than C alternatives, open source, etc...
I can saturate my 100 megabit link and not go above a few percent of processor usage using my SML FTP daemon. The bottlenecks are definitely the disk and network. (I am using the system call to copy file descriptors, anyway, so that part happens just as fast as the C version.) Honestly, I would estimate that my server uses at most 30% more processor time than wu_ftpd. If I actually thought that was slow, I'm sure I could bring it within 10% without much effort. If you think I'm wrong, you're going to have to give me some evidence.
For the vast vast majority of users, nobody needs even close to 100 megabits. For the people runing cdrom.com, or whatever, well, maybe a high performance ftp server is in order. These people hopefully have someone who can maintain it and keep up to date on patches. But for the 99.99% of users who install linux and the default FTP server on a sub-100mbit link (ESPECIALLy home users), the security liabilities of the C version far outweigh the imperceptible speed difference.
I guess my point is, high level langauges exist that make writing network applications easier. Even Java, since it has garbage collection and value-semantics strings, is certainly easier than C.
> But you need to get the data to C to do anything > usefull with it in most cases anyway.
Well, this is true, but you can encapsulate these in libraries and never think about C code. Still, wouldn't you agree that the more code written in a high-level safe language, the better? (At least for security reasons?)
I am glad to see where python is going; it seems to have a rather clean design, and they like to take good ideas out of the programming languages community. But it is still "just" a scripting language; its semantics preclude an efficient implementation (and make it harder to develop large programs).
Not really. Parsing is easy in high level languages, especially for text-based protocols like FTP, HTTP, and Gnutella. Perl is not special in its ability to manipulate strings! Arranging data is usually easy, too. I challenge you to check out my SML code for an FTP daemon and tell me where it is awkward because of the need to parse data (in fact, I think it is far more elegant than the C version!):
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/t om 7misc/net/mlftpd/
By the way, if the microsoft product you're referring to is the recent Stackguard-like option in their.NET C++ compiler, then you're wrong. This was a popularized misunderstanding (as seen on slashdot and elsewhere). Their code did not introduce any buffer overflows; it simply is not a complete protection against certain kinds of buffer overflows when using unsafe functions like strcpy.
Still, you are right that there have been language infrastructure bugs that have led to exploits (the JVM once had such a bug, for instance).
I agree with you in theory, but in reality we have seen very few compiler flaws and very many application flaws. Writing compilers for high-level languages isn't all that hard, anyway.
I disagree that buffer overflows can be easily avoided. If they are so easy to avoid, why do we continue to see them? Practically every popular network software written by anyone has fallen to a buffer overflow at one time. I also disagree that C code is easy to audit and verify. Wu_FTPD is over 24,000 lines long, and I can't imagine ever trying to think through the security of such a large system on pure willpower. Safe languages give you the benefit of computer checking, and this frees up your mind to think about more important things (such as the security problems that compilers can't check!)
An AC flames, (I know this doesn't warrant a response, but hey, I'm in the mood...)
> Oh, and your other attempt at a rant is equally > ignorant and distorted, you are obviously a php > script kiddie. Go learn C, stupid.
I dunno what your vendetta is against me, but you're wrong about me being ignorant. I happen to know C very well (I went through a phase where I thought it was the greatest, too -- go ahead, quiz me!), and currently I'm studing programming languages for my PhD in CS. I don't use PHP.
> Third buffer overflows are quite never > impossible, the use of word "impossible" > regarding a security issue is screaming > ignorance on your part.
Buffer overflows are impossible in a safe language like SML or Java. In fact, with a formal definition of a language (like SML has), one can prove this. It's possible for the compiler or virtual machine (for Java) to be flawed, but in that case, only one piece of code needs to be fixed. Upcoming technologies like certifying compilers and typed assembly language will make even this impossible.
C is popular, but just because something is, doesn't mean it ought. I really hope you open your mind and try some new things!
> In the case of OpenBSD, they don't use much > other than C where possible because the've > audited their libc.
Well, the fact that even libraries host security holes is a further reason not to use unsafe languages. There's no reason globbing code needs to be written in C. The corresponding Java or SML libraries would automatically not be vulnearable to heap corruption as libc was.
(I wasn't suggesting C++, by the way, since C++ is not a safe language, and so not much more secure than C.)
What? I don't think you know what you're saying. In any modern operating system, it's not possible for one process to write over the memory of another. Furthermore, saying that this is a Java exploit when it necessitates another process in another language is totally missing the point.
If a hacker exploited one process this way, then why would he bother to exploit the java program rather than just execute whatever code he plans on executing?
You are still totally wrong and I WILL be surprised if something like that happens.
I'm not suggesting ada. Not all safe languages are as perverse. However, if indeed new language ideas are too hard to learn for C programmers, then Java is a totally appropriate choice. (Personally I prefer more powerful and more efficient languages, like say SML.)
I don't agree with your assessment that safe high-level languages necessarily perform badly. (What is the difference between speed and performance?) But, let's forget about that.
What is "OS-level" about an ftp daemon? BIND? Mozilla? Gnutella? All sorts of network (and other) applications are written in C, even though there certainly isn't any need for performance or device-level bit manipulation. (At least, I would place security way above performance!)
Cyclone is actually from Cornell, by the way. It's a good project for moving systemsy people away from C, but there are already mature programming languages that are not slow, and yet are secure by default. (Try SML or O'Caml, for instance.)
This is totally wrong. It's not possible to overwrite pointers with arbitrary values in Java.
Certain C++ idioms can make things easier, it's true, but you are always subject to heap corruption vulnerabilities, double-frees, etc. C++ just isn't a safe language like Java is. (Even though I'm not so keen on Java, I sure do wish people would use it or something like it when they purport to be writing "secure" code.)
Huh? Buffer overflows don't have anything to do with context switches. They are just an artifact of the typical calling convention used, and the exploit happens entirely in user land. You're right that the code doesn't need to be on the stack, but that's usually the easiest place to put it (if there is some static buffer you're overflowing, you put the code in that buffer as part of the overflow). That's because stack locations are much easier to predict than heap locations.
Making the stack non-executable would make certain kinds of exploits much harder to write, but it also precludes some tricks that compilers use where they actually do need an executable stack.
I can't believe there is not one mention of using a language other than C. Is it the systems community? Is it because of BSD's history?
I don't know why this idea fails to even come up. Network servers are bandwidth-limited, not cpu limited, and writing them in a safe high level language is not only easier, but makes buffer overflows impossible. Being easier to write also of course allows more time for optimization and for other security fixes. (For those that need really high-performance for their gigabit links, maybe a C version and very careful maintenance is possible. For home users, this prospect is ridiculous.)
C seems almost *designed* to allow for buffer overflow exploits. If we want secure programs, we should be starting from more secure foundations!
I think the real reason that american anime fanatics like japanese voice acting is that they're not japanese. NOT because it's any better than the english dub. If you're not listening in your native language (and especially if you don't even understand the language), then you're less likely to pick up on the awkwardness that a bad voice actor brings. Everything seems more "artistic" when you don't understand it.
That is my theory. For low-to-medium-budget anime, I'll bet the voice acting is just as bad, or worse, than the american dub. (For instance, the high-pitched girls' voices come to mind.)
However, you might be right that a big production like Cowboy Bebop has more thought going into the japanese voices, though.
That said, I usually watch a foreign film in the original language; it's just more fun. But for watching TV, when I am distracted by things around me or don't want to concentrate too hard, I prefer dubbing.
Thanks for not just folding on this, guys. I was worried for a bit there.
If the DMCA isn't going away, we at least have to show corporations that trying to make unsubstantiated threats will cost them more than they seek to gain -- in terms of popularity of the software and in terms of legal battles. I think they've got very little to stand on here (as opposed to the DeCSS case, which I think the DMCA was basically written for), so good luck in your fight.
I understand that. You had said that exactly the same reasoning applies as in the DeCSS case, which is not true. That's what I was pointing out.
I still maintain that the DMCA is not relevant, though. There is no "access" (nor a "technological measure" as far as I know); they are simply reverse-engineering a protocol and implementing a server for it. And in particular, this act is specifically exempted in the DMCA.
It's not exactly the same as DeCSS; DeCSS bypassed an encryption (CSS) to access a copyrighted work. Though there is a copyright (say, Warcraft II) involved here, and perhaps encryption (I don't know the protocol well enough), but the encryption does not control access to some copyrighted work in the same way that it does in DeCSS. While the DMCA seems to be written precisely for the DVD case, you have to make a real stretch in this situation.
So I see why Blizzard might not want people playing online with bad serials, but I don't see how the DMCA is relevant.
Your analysis is wrong. The relevant section of the DMCA prohibits the trafficking of devices that circumvent access controls for a copyrighted work.
Copyright already prohibits the thieving of digital products, and patent law protects ideas.
However, I do agree that the DMCA is inapplicable to bnetd. That's because there is no circumvention of access controls going on, and because there is a specific exception to the anti-circumvention clause for the purpose of developing interoperable software. (See my post "sound like bullshit" for more detail.)
Slashdot Mirror
Actually, in a long-running system (such as a network server), a garbage collector is an advantage, not a liability:
1. Memory leaks are not possible.
2. Heap compaction IS possible (the garbage collector can move around data rather like DOS defrag). That means that the heap loses its fragmented nature when necessary. It's true that a C program does less allocation, but the malloc model doesn't allow for the heap to be defragmented! So for a long running program, you are typically stuck with fragmented memory that can't be reused...
So I say garbage collected languages win on this point!
> I disagree. Hell, Mozilla was painfully slow on
> 350 Mhz Pentium II until about 0.9.5 or so. That
> doesn't mean it needed C, of course, but to ignore
> performance is a bad idea.
Lots of Mozilla is written in Javascript, which is one of the main reasons it is such a resource hog. I think the performance would actually improve if it were written in pure SML.
Mozilla is a bad example, though, because people actually do complain about the speed of their web browser. (And buffer overflows are less serious here!) I really mean to just argue for network *servers*. You're right to call me on that, but for say, ftpd, I think the choice is clear.
The JVM is probably written in C. Java the language doesn't suffer from all of these problems, just particular implementations may. (There have been security exploits based on bugs in the JVM before, yes.)
;)) Finally, C compilers also are subject to this "problem", so it has an equal disadvantage anyway.
When I say that a language is safe, I mean that the definition of the language doesn't permit "undefined behavior" (where in the case of a C buffer overflow, this leads to running of arbitrary code by an attacker). Java falls into this category. So does SML. Perl and Python do, too, though it is hard to say because they are only defined by their implementations. (So it is hard to separate the language from implementation.)
Perl and Python, because of their ability to execute commands on the system so easily or interpret code sent by an attacker, are subject to a different class of security holes. Because Perl (especially) attempts to make so much functionality available to the user, it often leads to hack-job scripts that are difficult to reason about. It is true, though, that these languages are "safe" in the sense that they don't permit crashes (that could lead to execution of machine code).
Why is it unfair to mention that perl has had oveflows? I merely want to challenge the notion that slashdot folks seem to have that buffer overflows are an easy thing to avoid, and that they're only made by "bad" programmers. How can you say that "apparently they're all gone now"?
Some safe languages (or, say, natively compiled Java) don't have virtual machines. As far as I know, it's difficult to have a bug in a compiler that leads to exploitable security holes. It is certainly possible, but would take a much stranger situation than the ones that typically cause buffer overflows in C programs! And of course, fixing the compiler would fix all of the programs written using it automatically. (Well, after recompiling.
As for source code, I'm pretty sure there are open source implementations of the JVM. I am not a big java fan, myself. Yes, I have the source to my SML compiler.
> Not to detract from your main point, which is a
> good one and well made, but that particular
> statement is pretty dubious.
OK, you're right. I guess I what I really meant to say is, "For the home user with a powerful computer and relatively small bandwidth, CPU performance of network applications is nowhere near as important as security is."
I still think SML or O'Caml could take off with hakers, but I'm still trying to figure out a way to convince them to try something new. It's really not that hard, and the interfaces to system libraries are actually rather straightforward.
Well, I did it for FTP (in SML) at least:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tom 7misc/net/mlftpd/
In fact, it was very easy -- it took me about a weekend to get it working, and then a few days of tinkering to polish it off. That included writing an MD5 crypt library, and mechanisms for writing network daemons that I intend to re-use for later projects.
I don't know why it is, but there is this sort of gut reaction that the slashdot crowd has about this kind of stuff (maybe it comes from UNIX's history). Since it's not written in C, it is seen as somehow inferior. Even though it supports 99% of the RFC (I would finish it off if people cared..), is 100% buffer-overflow free, much shorter and elegant than C alternatives, open source, etc...
No, I'm not nuts!
I can saturate my 100 megabit link and not go above a few percent of processor usage using my SML FTP daemon. The bottlenecks are definitely the disk and network. (I am using the system call to copy file descriptors, anyway, so that part happens just as fast as the C version.) Honestly, I would estimate that my server uses at most 30% more processor time than wu_ftpd. If I actually thought that was slow, I'm sure I could bring it within 10% without much effort. If you think I'm wrong, you're going to have to give me some evidence.
For the vast vast majority of users, nobody needs even close to 100 megabits. For the people runing cdrom.com, or whatever, well, maybe a high performance ftp server is in order. These people hopefully have someone who can maintain it and keep up to date on patches. But for the 99.99% of users who install linux and the default FTP server on a sub-100mbit link (ESPECIALLy home users), the security liabilities of the C version far outweigh the imperceptible speed difference.
Well, I'll agree with you there. ;)
I guess my point is, high level langauges exist that make writing network applications easier. Even Java, since it has garbage collection and value-semantics strings, is certainly easier than C.
> But you need to get the data to C to do anything
> usefull with it in most cases anyway.
Well, this is true, but you can encapsulate these in libraries and never think about C code. Still, wouldn't you agree that the more code written in a high-level safe language, the better? (At least for security reasons?)
I think you mean, "continuations". ;)
I am glad to see where python is going; it seems to have a rather clean design, and they like to take good ideas out of the programming languages community. But it is still "just" a scripting language; its semantics preclude an efficient implementation (and make it harder to develop large programs).
Not really. Parsing is easy in high level languages, especially for text-based protocols like FTP, HTTP, and Gnutella. Perl is not special in its ability to manipulate strings! Arranging data is usually easy, too. I challenge you to check out my SML code for an FTP daemon and tell me where it is awkward because of the need to parse data (in fact, I think it is far more elegant than the C version!):
t om 7misc/net/mlftpd/
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/
All the FTP parsing code is in ftp.sml.
By the way, if the microsoft product you're referring to is the recent Stackguard-like option in their .NET C++ compiler, then you're wrong. This was a popularized misunderstanding (as seen on slashdot and elsewhere). Their code did not introduce any buffer overflows; it simply is not a complete protection against certain kinds of buffer overflows when using unsafe functions like strcpy.
Still, you are right that there have been language infrastructure bugs that have led to exploits (the JVM once had such a bug, for instance).
I agree with you in theory, but in reality we have seen very few compiler flaws and very many application flaws. Writing compilers for high-level languages isn't all that hard, anyway.
I disagree that buffer overflows can be easily avoided. If they are so easy to avoid, why do we continue to see them? Practically every popular network software written by anyone has fallen to a buffer overflow at one time. I also disagree that C code is easy to audit and verify. Wu_FTPD is over 24,000 lines long, and I can't imagine ever trying to think through the security of such a large system on pure willpower. Safe languages give you the benefit of computer checking, and this frees up your mind to think about more important things (such as the security problems that compilers can't check!)
An AC flames, (I know this doesn't warrant a response, but hey, I'm in the mood...)
> Oh, and your other attempt at a rant is equally > ignorant and distorted, you are obviously a php
> script kiddie. Go learn C, stupid.
I dunno what your vendetta is against me, but you're wrong about me being ignorant. I happen to know C very well (I went through a phase where I thought it was the greatest, too -- go ahead, quiz me!), and currently I'm studing programming languages for my PhD in CS. I don't use PHP.
> Third buffer overflows are quite never
> impossible, the use of word "impossible"
> regarding a security issue is screaming
> ignorance on your part.
Buffer overflows are impossible in a safe language like SML or Java. In fact, with a formal definition of a language (like SML has), one can prove this. It's possible for the compiler or virtual machine (for Java) to be flawed, but in that case, only one piece of code needs to be fixed. Upcoming technologies like certifying compilers and typed assembly language will make even this impossible.
C is popular, but just because something is, doesn't mean it ought. I really hope you open your mind and try some new things!
AC writes,
> In the case of OpenBSD, they don't use much
> other than C where possible because the've
> audited their libc.
Well, the fact that even libraries host security holes is a further reason not to use unsafe languages. There's no reason globbing code needs to be written in C. The corresponding Java or SML libraries would automatically not be vulnearable to heap corruption as libc was.
(I wasn't suggesting C++, by the way, since C++ is not a safe language, and so not much more secure than C.)
What? I don't think you know what you're saying. In any modern operating system, it's not possible for one process to write over the memory of another. Furthermore, saying that this is a Java exploit when it necessitates another process in another language is totally missing the point.
If a hacker exploited one process this way, then why would he bother to exploit the java program rather than just execute whatever code he plans on executing?
You are still totally wrong and I WILL be surprised if something like that happens.
I'm not suggesting ada. Not all safe languages are as perverse. However, if indeed new language ideas are too hard to learn for C programmers, then Java is a totally appropriate choice. (Personally I prefer more powerful and more efficient languages, like say SML.)
I don't agree with your assessment that safe high-level languages necessarily perform badly. (What is the difference between speed and performance?) But, let's forget about that.
What is "OS-level" about an ftp daemon? BIND? Mozilla? Gnutella? All sorts of network (and other) applications are written in C, even though there certainly isn't any need for performance or device-level bit manipulation. (At least, I would place security way above performance!)
Cyclone is actually from Cornell, by the way. It's a good project for moving systemsy people away from C, but there are already mature programming languages that are not slow, and yet are secure by default. (Try SML or O'Caml, for instance.)
This is totally wrong. It's not possible to overwrite pointers with arbitrary values in Java.
Certain C++ idioms can make things easier, it's true, but you are always subject to heap corruption vulnerabilities, double-frees, etc. C++ just isn't a safe language like Java is. (Even though I'm not so keen on Java, I sure do wish people would use it or something like it when they purport to be writing "secure" code.)
Huh? Buffer overflows don't have anything to do with context switches. They are just an artifact of the typical calling convention used, and the exploit happens entirely in user land. You're right that the code doesn't need to be on the stack, but that's usually the easiest place to put it (if there is some static buffer you're overflowing, you put the code in that buffer as part of the overflow). That's because stack locations are much easier to predict than heap locations.
Making the stack non-executable would make certain kinds of exploits much harder to write, but it also precludes some tricks that compilers use where they actually do need an executable stack.
I can't believe there is not one mention of using a language other than C. Is it the systems community? Is it because of BSD's history?
I don't know why this idea fails to even come up. Network servers are bandwidth-limited, not cpu limited, and writing them in a safe high level language is not only easier, but makes buffer overflows impossible. Being easier to write also of course allows more time for optimization and for other security fixes. (For those that need really high-performance for their gigabit links, maybe a C version and very careful maintenance is possible. For home users, this prospect is ridiculous.)
C seems almost *designed* to allow for buffer overflow exploits. If we want secure programs, we should be starting from more secure foundations!
For more detail, check my previous rant, "C lang remains inappropriate for network daemons": http://slashdot.org/comments.pl?sid=24271&cid=2629 013
I gotta agree with you that the first episode was boring!
Here's an unpopular opinion:
I think the real reason that american anime fanatics like japanese voice acting is that they're not japanese. NOT because it's any better than the english dub. If you're not listening in your native language (and especially if you don't even understand the language), then you're less likely to pick up on the awkwardness that a bad voice actor brings. Everything seems more "artistic" when you don't understand it.
That is my theory. For low-to-medium-budget anime, I'll bet the voice acting is just as bad, or worse, than the american dub. (For instance, the high-pitched girls' voices come to mind.)
However, you might be right that a big production like Cowboy Bebop has more thought going into the japanese voices, though.
That said, I usually watch a foreign film in the original language; it's just more fun. But for watching TV, when I am distracted by things around me or don't want to concentrate too hard, I prefer dubbing.
Thanks for not just folding on this, guys. I was worried for a bit there.
If the DMCA isn't going away, we at least have to show corporations that trying to make unsubstantiated threats will cost them more than they seek to gain -- in terms of popularity of the software and in terms of legal battles. I think they've got very little to stand on here (as opposed to the DeCSS case, which I think the DMCA was basically written for), so good luck in your fight.
I understand that. You had said that exactly the same reasoning applies as in the DeCSS case, which is not true. That's what I was pointing out.
I still maintain that the DMCA is not relevant, though. There is no "access" (nor a "technological measure" as far as I know); they are simply reverse-engineering a protocol and implementing a server for it. And in particular, this act is specifically exempted in the DMCA.
It's not exactly the same as DeCSS; DeCSS bypassed an encryption (CSS) to access a copyrighted work. Though there is a copyright (say, Warcraft II) involved here, and perhaps encryption (I don't know the protocol well enough), but the encryption does not control access to some copyrighted work in the same way that it does in DeCSS. While the DMCA seems to be written precisely for the DVD case, you have to make a real stretch in this situation.
So I see why Blizzard might not want people playing online with bad serials, but I don't see how the DMCA is relevant.
Your analysis is wrong. The relevant section of the DMCA prohibits the trafficking of devices that circumvent access controls for a copyrighted work.
Copyright already prohibits the thieving of digital products, and patent law protects ideas.
However, I do agree that the DMCA is inapplicable to bnetd. That's because there is no circumvention of access controls going on, and because there is a specific exception to the anti-circumvention clause for the purpose of developing interoperable software. (See my post "sound like bullshit" for more detail.)