Sadly, I don't think it would help. I thought about this for a moment, and came up with the following... someone please feel free to correct me if I'm mistaken.
Where retaddr#2 and ebp#2 are the return address from strcpy back into BadFunction, and the corresponding stack frame ptr respectively.
Notice that we can now overflow badBuf to scribble on retaddr#2. Thus, when strcpy returns, we can still jump to arbitrary locations. Slightly different approach, same effect.
Again - this *seems* like it would work, but if anyone can see a flaw, please correct me.
Hmmm... I'm using IE5. It looks like it's doing whatever it can to try and launch a malicious executable.
The machines that are hitting me, although not in the same subnet, are not too far off, lending credence to the suspicion that the virus attacks nearby machines first.
Interesting that he turned himself in - perhaps this does lend credence to the idea that he really didn't know what he was doing. Although, to be fair, if you download a worm creation kit, use it to create a worm, and then post it to Usenet, it seems unlikely that you wouldn't be aware of the potential consequences.
Unfortunately, although the GL demos look nice, they don't really reveal much in terms of performance speed. In particular, demos like "gears" do very little CPU work.
Although the idea may be sound, also, I suspect they're going to have a great deal of difficulty achieving the necessary momentum to attract developers, particularly without a solid GUI framework, and such sketchy documentation.
(Besides, everyone and their dog has written a PlayStation emulator by now - if you just want browser games based on a common development platform, why not use those:)
Re:Small util for Windows to listen on port 80?
on
Code Redux
·
· Score: 1
I just wrote it REALLY fast (which is why the code is so ugly), so I haven't tested it too thoroughly (ie. in the wild), but it looks like it oughta work.
Naturally, I expressly disclaim all responsibility for anything bad that happens should you choose to use this program.
None of the applications you mention use raw sockets. They all (like 99% of network apps) use TCP or UDP sockets. The application never gets to touch the raw IP header data. There's no need.
Yes - I know that promiscuous mode and raw sockets are fairly unrelated. However, APIs that permit raw socket access frequently also permit the application to invoke promiscuous mode. This is certainly the case using when using Windows NDIS drivers under 98 (eg. winpcap). I have written network analysis/routing tools under Windows and Linux, and as a general rule of thumb, if you can do one, you can do the other.
I'm not blaming raw sockets for anything! I fully agree that Gibson and Cringely are in the wrong. Network security doesn't arise from crossing your fingers and hoping that every box on your network is going to play fair.
There's a special-case ICMP interface under 98/95, yes, but it doesn't actually let you write your own raw IP headers.
If you want to do real raw IP under 98, you need to go down to the NDIS layer, typically by installing a driver, such as the one that comes with winpcap.
It is true, however, that this can be done without a reboot - EtherPeek certainly manages it - and thus the slightly more determined virus writer can achieve raw packet spoofing under any of the existing Windows OS's.
Filling in the gaps Cringely left, I'll postulate that each packet would be digitally signed with the private key of the individual authorizing that packet. Handling of the packet at the receiving host would be dependent on that host's trust level of the signer. When an infected IIS server S1 makes a TCP connection to a clean IIS server S2, the connection would be at a minimal (public) privilege level. This would cause the resulting thread|process to run at the untrusted/public level. Then, when the buffer overflow hands control to the attacking worm, the worm has only gained 'public' level of access, rather than root. (Yes I know they don't call it root.) In other words, this is a redesign of the OS kernel, not just the protocol. Otherwise it's meaningless.
I may be mistaken, but this sounds pretty much equivalent to just making sure that your httpd (for instance) daemon (and any chilren it spawns) don't run as root. I don't think you need a whole new packet-level protocol for this.
I believe that authentication and crypto are best left to higher-level protocols. IP is for shunting packets around - nothing more, nothing less. If we really want to avoid spoofing, a much better way would be to make routers stricter with regard to packets arriving on an unexpected network interface.
Yes, but that wasn't the point. Running an OS that provides access to raw sockets doesn't make your machine any more vulnerable, agreed. However, if your machine is compromised, it can be made to send a whole load of spoofed packets to a target, thus making it much harder for the target to ascertain where they're coming from. This, says Cringely, is a bad thing.
Furthermore, (I'm not sure about this - can someone who knows more about XP comment?), the ability to generate raw IP packets often goes hand-in-hand with the ability to put the ethernet card in 'promiscuous' mode, and sniff all packets on the local ethernet. Imagine a virus that, once installed, sniffs for passwords in local LAN traffic. Not good.
Of course, this is all beside the point anyway - machines can be made to spoof packets already!. We need to be making routers more fussy about which interfaces packets need to arrive on, rather than crossing our fingers and hoping that every host on the internet is well-behaved.
Raw sockets are an application programming interface (API) whereby the application is able to control the contents of IP packet headers directly. This means that an application, for instance, can transmit a packet with a forged source IP address - thus disguising its origin. This is often used to conceal the source of a DoS attack.
Linux provides raw sockets, but only the root user is able to utilise them (and rightly so). Cringely's article doesn't make it clear as to whether or not there's any kind of user-based protection under XP, or whether anything and everything can access raw sockets under XP.
Although most end-users are running a MS-based operating system, there is simply too much non-MS underlying internet infrastructure for such a radical change in protocol. TCP/IP is going to be around for a very long time.
Furthermore, how is it exactly that TCP/MS would prevent things like Code Red from happening? An application is vulnerable to stack overflow exploits because of the application code itself, not because of the protocol through which it receives data. Registering the ports that an application listens on won't help if the app contains a vulnerability.
Cringely goes on to suggest that all connections be traceable - well, that's fine, except that it doesn't solve the problem of people launching viruses from public terminals, or obtaining free trial dialup accounts using fictitious information. Digitally signing specific applicaitons with an Active-X control style GUID, and only granting access to validly signed applications might help, but I can't see developers embracing that idea. Even if they did, it only takes one compromised certificate to release any number of malicious programs.
And did Gibson actually write Zone Alarm? Cringely seems to think so, but it's marketed by Zone Labs, not GRC.COM. Anyone know for sure?
Although you don't think it would fly, surely the point is that they're making use of the functionality of the GPL code, and thus should be subject to all the requirements that the GPL entails.
If not, I don't really see what benefit the GPL provides - companies are essentially free to take from the open source community without giving back anything other than a tiny RPC or IPC wrapper.
(Of course this would bring up more difficulties and interesting questions - to what exent does a web browser "make use of the functionality" of Apache?).
As for the latency point, I think it's a non-issue - at least in this case. Video encoding (heck, even audio encoding) are CPU intensive things - the amount of time to transmit the data across a localhost TCP connection (or even use shared memory) is negligible in comparison to the time spent in the encoding routines.
Much of the debate between Vidomi and proponents of the GPL has been prolonged by Vidomi's incessant questioning of what exactly consitutes linkage. They have maintained from the very beginning that they don't think they're doing anything wrong, since the GPL code is in a separate DLL.
Of course, as many have pointed out, this is a fallacy - a DLL is, after all, another form of library - even if the code is not statically linked, it's linked nonetheless. The LGPL is designed as a less restrictive form of the GPL specifically for this purpose - enabling the distribution of a library without the "release your source" requirements of the GPL. Since Avery did not use the LGPL, we can assume that he intended the full requirements of the GPL to apply. In this case, fortunately, Vidomi has conceded.
Unfortunately, I can see future confusion arising the same question - what constitutes linkage? It's fairly trivial, for example, to write a small standalone application that links directly with a GPL library/DLL, and listens on a local TCP port. On receiving encoded commands from the TCP, it translates these to function calls into the GPL code, and returns the results back over the TCP connection - RPC style. Can the offending company, having written a trivial RPC layer, then release the source code for the server program, while keeping the client code closed-source?
Although the client is making extensive use of GPL code, it's not linked with it... it's in a completely different process. In fact, it could be on a completely different machine.
This strikes me as a relatively easy way for companies to get around the requirements of the GPL. Anyone have any thoughts on this?
Yeah, it was an interesting book but, as you state, more so for the descriptions of the builders' environment than the actual machine/theory behind it.
I'm fairly sure their premise was unsound to begind with. Roulette really is a random game - the whole point is that the outcome, much like rolling a die, is based on the composite effect of millions of forces along the ball's path - air pressure, friction, rebounds. They were trying to predict an outcome based on only a few observations, which, furthermore, were subject to human judgement and reflexes!
I gather that MS has very strict guidelines as to what developers can and can't do with the XBox hard drive. As I understand, it's primarily to be used for savegame info and for cacheing the CDROM. Downloading patches, plugins, etc... is definately not allowed.
I wonder if Sony has similar requirements. Given the profusion of MMORPGS, and the coolness of being able to download new gfx resources and objects on the fly, I think a hard drive opens up a whole load of possibilities.
I find it surprising that we still haven't found an ideal solution to spam.
To me, an ideal solution would identify mass-mailings with 100% accuracy, identify offenders with 100% accuracy, and auto-notify their providers, all without me ever laying eyes on it.
The closest thing right now is SpamCop, which I think is great.
www.privacyrights.org has a section dealing with these issues. They also have a useful list of contact addresses (although most are snail-mail).
This kind of thing is sickening. What with the continuing erosion of consumer rights and abuse of the patent office, this country is rapidly becoming a place where unless you're a big business, you're screwed.
There's a difference between using someone else's public domain code in your own software and charging for it, and effectively removing someone else's code from the public domain.
The point is that the data that we spent thousands of collective hours entering is not publically available elsewhere!
At the risk of encouraging a troll... There are so many basic misconceptions in your short post that I'm not sure where to begin.
Gracenote has done nothing wrong, they took information that was put in the public domain, included some value-added features and sold is as a product.
You miss the critical point - as well as selling the CD data as a product, they removed it from the public domain. This is something they had no right to do, since the data was contributed by the community, on the understanding that it would remain in the public domain.
The first amendment gives every one in the US (including corporations) the right to freedom of business!
Uh... What?
All these people that are complaining about having their hard work "stolen" are probably the same people that contribute to open-source software -- they will not get any compensation or recognition for that either, and they don't complain, so what is the problem?
You don't understand Open-Source very well, do you. Even if you did, your analogy is flawed. There are many reasons for developing Open Source software. One of them is to fix or improve something that needs fixing, and make the benefits that your code brings available to everyone, for the good of the community. My Open Source software is freely available for everyone to use/enjoy, and that's the way I want it. What Gracenote did was to take my (and others) work, and remove that free availability! Again - something they had no right to do.
If the machines in question are spoofing source IP addresses, then at some point along the path to the target box, a router will be encountered where the IP packet arrives on an unexpected interface. At this point, you know the packet is spoofed, and can drop it. Of course, this requires a degree of intelligence on the part of the routers, but nothing too sophisticated
Routers could also be modified to detect ping floods, SYN floods, smurf attacks, and most of the other forms of DOS, using some fairly simple heuristics.
Of course, there's nothing to prevent a DOS author from merely hitting a target with a *load* of HTTP GET requests that look like legitimate hits - no good way to distinguish there. But that's not what Gibson was talking about - he was talking about the spoofing ability of Win boxes.
My point is that any network infrastructure that relies on expecting all the attached hosts to behave themselves is inherently flawed. Removing spoofing capabilities from the Winsock libs is effectively equivalent to security by obscurity - it only takes one person to find a workaround/write a driver, and you're screwed.
Yes, but the problem here is that average Joe Public doesn't want to hear the facts. They want to hear an over-dramatized version of events, where aircraft navigation systems are at the mercy of 13 year old kids. Gibson plays to this, and in doing so, serves to perpetuate the public's general misunderstanding of computer security.
Not only that, but he's also factually incorrect about Win98 machines being unable to spoof IP headers. Furthermore, his suggestion that this functionality should be removed to "protect" us all is ridiculous. Anyone who wants to spoof packets badly enough will be able to do so - it only takes one person to write a special device driver, et voila! DOS avoidance should be at the network/router level, and not rely on the ridiculous assumption that all hosts attached to the internet will behave themselves.
(and what's with the highlighting of certain random sentences all over his page?! It's like the guy desperately wants to be writing for a magazine)
Dynamic Linking, Static Linking, Separate EXE - it really shouldn't matter. No matter how Vidomi tries to weasel out of describing their product as a derivative work, the fact remains that they make use of the functionality provided by VirtuaDub.
It seems fairly clear that they are trying to get something for nothing. The excuse that they "have not heard back from the FSF" is a ridiculous stalling tactic. If they wish to act in good faith (and they claim that they do), the correct thing to do would be to remove all traces of GPL code from their product until an agreement is reached.
I've checked their forums - every one of their posts is of the form "How can we bring our product into compliance?". Every response is of the form: "Simple - remove all the GPL code, or release the source to your product!". They seem to ignore all these posts, and come back with "What if we tried weaselling out of our responsibility using sneaky tactic X? Would that work?".
Slashdot Mirror
Sadly, I don't think it would help. I thought about this for a moment, and came up with the following... someone please feel free to correct me if I'm mistaken.
...
Most buffer overflows are due to code such as:
void BadFunction(void)
{
char badBuf[100];
strcpy(badBuf,longString);
So, your stack looks like:
--> increasing memory address
[badBuf 100 bytes][ebp][return addr]
Standard overflow attacks involve scribbling on the return addr.
Now, let's suppose your stack goes the other way... once the code enters the strcpy function, we'll have:
--> increasing memory address
[return addr][ebp][badBuf][retaddr#2][ebp#2]...
Where retaddr#2 and ebp#2 are the return address from strcpy back into BadFunction, and the corresponding stack frame ptr respectively.
Notice that we can now overflow badBuf to scribble on retaddr#2. Thus, when strcpy returns, we can still jump to arbitrary locations. Slightly different approach, same effect.
Again - this *seems* like it would work, but if anyone can see a flaw, please correct me.
Hmmm... I'm using IE5. It looks like it's doing whatever it can to try and launch a malicious executable.
The machines that are hitting me, although not in the same subnet, are not too far off, lending credence to the suspicion that the virus attacks nearby machines first.
Wow - I've got about 1000 similar hits in my logs, starting from around 6.30am this morning. From a variety of different IP addresses.
63.73.31.242 just hit me 16 times.
Going to http://63.73.31.242 indicates:
"National Aerospace Documentation Home Page"
and attempts to launch a "readme.exe" executable immediately.
Just checked another site: 63.168.150.72 - plain old IIS page, but attempts to launch the same executable.
So, we have Code Red, with an added attempt to launch a (no doubt) malicious executable from infected pages.
Interesting that he turned himself in - perhaps this does lend credence to the idea that he really didn't know what he was doing. Although, to be fair, if you download a worm creation kit, use it to create a worm, and then post it to Usenet, it seems unlikely that you wouldn't be aware of the potential consequences.
Unfortunately, although the GL demos look nice, they don't really reveal much in terms of performance speed. In particular, demos like "gears" do very little CPU work.
:)
Although the idea may be sound, also, I suspect they're going to have a great deal of difficulty achieving the necessary momentum to attract developers, particularly without a solid GUI framework, and such sketchy documentation.
(Besides, everyone and their dog has written a PlayStation emulator by now - if you just want browser games based on a common development platform, why not use those
Try this.
I just wrote it REALLY fast (which is why the code is so ugly), so I haven't tested it too thoroughly (ie. in the wild), but it looks like it oughta work.
Naturally, I expressly disclaim all responsibility for anything bad that happens should you choose to use this program.
None of the applications you mention use raw sockets. They all (like 99% of network apps) use TCP or UDP sockets. The application never gets to touch the raw IP header data. There's no need.
Strags
Yes - I know that promiscuous mode and raw sockets are fairly unrelated. However, APIs that permit raw socket access frequently also permit the application to invoke promiscuous mode. This is certainly the case using when using Windows NDIS drivers under 98 (eg. winpcap). I have written network analysis/routing tools under Windows and Linux, and as a general rule of thumb, if you can do one, you can do the other.
I'm not blaming raw sockets for anything! I fully agree that Gibson and Cringely are in the wrong. Network security doesn't arise from crossing your fingers and hoping that every box on your network is going to play fair.
Strags
There's a special-case ICMP interface under 98/95, yes, but it doesn't actually let you write your own raw IP headers.
If you want to do real raw IP under 98, you need to go down to the NDIS layer, typically by installing a driver, such as the one that comes with winpcap.
It is true, however, that this can be done without a reboot - EtherPeek certainly manages it - and thus the slightly more determined virus writer can achieve raw packet spoofing under any of the existing Windows OS's.
Strags
Filling in the gaps Cringely left, I'll postulate that each packet would be digitally signed with the private key of the individual authorizing that packet. Handling of the packet at the receiving host would be dependent on that host's trust level of the signer. When an infected IIS server S1 makes a TCP connection to a clean IIS server S2, the connection would be at a minimal (public) privilege level. This would cause the resulting thread|process to run at the untrusted/public level. Then, when the buffer overflow hands control to the attacking worm, the worm has only gained 'public' level of access, rather than root. (Yes I know they don't call it root.) In other words, this is a redesign of the OS kernel, not just the protocol. Otherwise it's meaningless.
I may be mistaken, but this sounds pretty much equivalent to just making sure that your httpd (for instance) daemon (and any chilren it spawns) don't run as root. I don't think you need a whole new packet-level protocol for this.
I believe that authentication and crypto are best left to higher-level protocols. IP is for shunting packets around - nothing more, nothing less. If we really want to avoid spoofing, a much better way would be to make routers stricter with regard to packets arriving on an unexpected network interface.
Strags
Yes, but that wasn't the point. Running an OS that provides access to raw sockets doesn't make your machine any more vulnerable, agreed. However, if your machine is compromised, it can be made to send a whole load of spoofed packets to a target, thus making it much harder for the target to ascertain where they're coming from. This, says Cringely, is a bad thing.
Furthermore, (I'm not sure about this - can someone who knows more about XP comment?), the ability to generate raw IP packets often goes hand-in-hand with the ability to put the ethernet card in 'promiscuous' mode, and sniff all packets on the local ethernet. Imagine a virus that, once installed, sniffs for passwords in local LAN traffic. Not good.
Of course, this is all beside the point anyway - machines can be made to spoof packets already!. We need to be making routers more fussy about which interfaces packets need to arrive on, rather than crossing our fingers and hoping that every host on the internet is well-behaved.
Raw sockets are an application programming interface (API) whereby the application is able to control the contents of IP packet headers directly. This means that an application, for instance, can transmit a packet with a forged source IP address - thus disguising its origin. This is often used to conceal the source of a DoS attack.
Linux provides raw sockets, but only the root user is able to utilise them (and rightly so). Cringely's article doesn't make it clear as to whether or not there's any kind of user-based protection under XP, or whether anything and everything can access raw sockets under XP.
Strags
SOCK_RAW access permits applications to spoof source IP addresses, thus disguising the source of a DoS attack.
Although most end-users are running a MS-based operating system, there is simply too much non-MS underlying internet infrastructure for such a radical change in protocol. TCP/IP is going to be around for a very long time.
Furthermore, how is it exactly that TCP/MS would prevent things like Code Red from happening? An application is vulnerable to stack overflow exploits because of the application code itself, not because of the protocol through which it receives data. Registering the ports that an application listens on won't help if the app contains a vulnerability.
Cringely goes on to suggest that all connections be traceable - well, that's fine, except that it doesn't solve the problem of people launching viruses from public terminals, or obtaining free trial dialup accounts using fictitious information. Digitally signing specific applicaitons with an Active-X control style GUID, and only granting access to validly signed applications might help, but I can't see developers embracing that idea. Even if they did, it only takes one compromised certificate to release any number of malicious programs.
And did Gibson actually write Zone Alarm? Cringely seems to think so, but it's marketed by Zone Labs, not GRC.COM. Anyone know for sure?
Strags
Although you don't think it would fly, surely the point is that they're making use of the functionality of the GPL code, and thus should be subject to all the requirements that the GPL entails.
If not, I don't really see what benefit the GPL provides - companies are essentially free to take from the open source community without giving back anything other than a tiny RPC or IPC wrapper.
(Of course this would bring up more difficulties and interesting questions - to what exent does a web browser "make use of the functionality" of Apache?).
As for the latency point, I think it's a non-issue - at least in this case. Video encoding (heck, even audio encoding) are CPU intensive things - the amount of time to transmit the data across a localhost TCP connection (or even use shared memory) is negligible in comparison to the time spent in the encoding routines.
Cheers,
Strags
Much of the debate between Vidomi and proponents of the GPL has been prolonged by Vidomi's incessant questioning of what exactly consitutes linkage. They have maintained from the very beginning that they don't think they're doing anything wrong, since the GPL code is in a separate DLL.
Of course, as many have pointed out, this is a fallacy - a DLL is, after all, another form of library - even if the code is not statically linked, it's linked nonetheless. The LGPL is designed as a less restrictive form of the GPL specifically for this purpose - enabling the distribution of a library without the "release your source" requirements of the GPL. Since Avery did not use the LGPL, we can assume that he intended the full requirements of the GPL to apply. In this case, fortunately, Vidomi has conceded.
Unfortunately, I can see future confusion arising the same question - what constitutes linkage? It's fairly trivial, for example, to write a small standalone application that links directly with a GPL library/DLL, and listens on a local TCP port. On receiving encoded commands from the TCP, it translates these to function calls into the GPL code, and returns the results back over the TCP connection - RPC style. Can the offending company, having written a trivial RPC layer, then release the source code for the server program, while keeping the client code closed-source?
Although the client is making extensive use of GPL code, it's not linked with it... it's in a completely different process. In fact, it could be on a completely different machine.
This strikes me as a relatively easy way for companies to get around the requirements of the GPL. Anyone have any thoughts on this?
Strags
Yeah, it was an interesting book but, as you state, more so for the descriptions of the builders' environment than the actual machine/theory behind it.
I'm fairly sure their premise was unsound to begind with. Roulette really is a random game - the whole point is that the outcome, much like rolling a die, is based on the composite effect of millions of forces along the ball's path - air pressure, friction, rebounds. They were trying to predict an outcome based on only a few observations, which, furthermore, were subject to human judgement and reflexes!
I gather that MS has very strict guidelines as to what developers can and can't do with the XBox hard drive. As I understand, it's primarily to be used for savegame info and for cacheing the CDROM. Downloading patches, plugins, etc... is definately not allowed.
I wonder if Sony has similar requirements. Given the profusion of MMORPGS, and the coolness of being able to download new gfx resources and objects on the fly, I think a hard drive opens up a whole load of possibilities.
Strags
I find it surprising that we still haven't found an ideal solution to spam.
To me, an ideal solution would identify mass-mailings with 100% accuracy, identify offenders with 100% accuracy, and auto-notify their providers, all without me ever laying eyes on it.
The closest thing right now is SpamCop, which I think is great.
www.privacyrights.org has a section dealing with these issues. They also have a useful list of contact addresses (although most are snail-mail).
This kind of thing is sickening. What with the continuing erosion of consumer rights and abuse of the patent office, this country is rapidly becoming a place where unless you're a big business, you're screwed.
Strags
There's a difference between using someone else's public domain code in your own software and charging for it, and effectively removing someone else's code from the public domain.
The point is that the data that we spent thousands of collective hours entering is not publically available elsewhere!
Strags
At the risk of encouraging a troll... There are so many basic misconceptions in your short post that I'm not sure where to begin.
Gracenote has done nothing wrong, they took information that was put in the public domain, included some value-added features and sold is as a product.
You miss the critical point - as well as selling the CD data as a product, they removed it from the public domain. This is something they had no right to do, since the data was contributed by the community, on the understanding that it would remain in the public domain.
The first amendment gives every one in the US (including corporations) the right to freedom of business!
Uh... What?
All these people that are complaining about having their hard work "stolen" are probably the same people that contribute to open-source software -- they will not get any compensation or recognition for that either, and they don't complain, so what is the problem?
You don't understand Open-Source very well, do you. Even if you did, your analogy is flawed. There are many reasons for developing Open Source software. One of them is to fix or improve something that needs fixing, and make the benefits that your code brings available to everyone, for the good of the community. My Open Source software is freely available for everyone to use/enjoy, and that's the way I want it. What Gracenote did was to take my (and others) work, and remove that free availability! Again - something they had no right to do.
Strags
If the machines in question are spoofing source IP addresses, then at some point along the path to the target box, a router will be encountered where the IP packet arrives on an unexpected interface. At this point, you know the packet is spoofed, and can drop it. Of course, this requires a degree of intelligence on the part of the routers, but nothing too sophisticated
Routers could also be modified to detect ping floods, SYN floods, smurf attacks, and most of the other forms of DOS, using some fairly simple heuristics.
Of course, there's nothing to prevent a DOS author from merely hitting a target with a *load* of HTTP GET requests that look like legitimate hits - no good way to distinguish there. But that's not what Gibson was talking about - he was talking about the spoofing ability of Win boxes.
My point is that any network infrastructure that relies on expecting all the attached hosts to behave themselves is inherently flawed. Removing spoofing capabilities from the Winsock libs is effectively equivalent to security by obscurity - it only takes one person to find a workaround/write a driver, and you're screwed.
Yes, but the problem here is that average Joe Public doesn't want to hear the facts. They want to hear an over-dramatized version of events, where aircraft navigation systems are at the mercy of 13 year old kids. Gibson plays to this, and in doing so, serves to perpetuate the public's general misunderstanding of computer security.
Not only that, but he's also factually incorrect about Win98 machines being unable to spoof IP headers. Furthermore, his suggestion that this functionality should be removed to "protect" us all is ridiculous. Anyone who wants to spoof packets badly enough will be able to do so - it only takes one person to write a special device driver, et voila! DOS avoidance should be at the network/router level, and not rely on the ridiculous assumption that all hosts attached to the internet will behave themselves.
(and what's with the highlighting of certain random sentences all over his page?! It's like the guy desperately wants to be writing for a magazine)
Dynamic Linking, Static Linking, Separate EXE - it really shouldn't matter. No matter how Vidomi tries to weasel out of describing their product as a derivative work, the fact remains that they make use of the functionality provided by VirtuaDub.
It seems fairly clear that they are trying to get something for nothing. The excuse that they "have not heard back from the FSF" is a ridiculous stalling tactic. If they wish to act in good faith (and they claim that they do), the correct thing to do would be to remove all traces of GPL code from their product until an agreement is reached.
I've checked their forums - every one of their posts is of the form "How can we bring our product into compliance?". Every response is of the form: "Simple - remove all the GPL code, or release the source to your product!". They seem to ignore all these posts, and come back with "What if we tried weaselling out of our responsibility using sneaky tactic X? Would that work?".