14. Can the 64-bit version of Windows Whistler read, write, and boot from MBR disks?
The 64-bit version of Windows Whistler can read and write MBR disks, but cannot boot from MBR disks.
15. Can the 32-bit version of Windows Whistler read, write, and boot from GPT disks?
No. The 32-bit version will see only the Protective MBR. The EE partition will not be mounted or otherwise exposed to application software.
16. Can the 32-bit version of Windows Whistler read, write, and boot from MBR disks?
Yes.
So this really applies only to the 64-bit version - the 32-bit version won't even support GPT drives.
55. Is it possible to make a sector-by-sector copy of a GPT disk?
No. The Disk and Partition GUIDs will no longer be unique. This must never happen. You can make a sector-by-sector copy of the contents of ESP or basic data partitions.
Perhaps I misunderstand - I assumed the the GUIDS would be unique per installed OS, not unique per user. What possible reason could there be for this other than uniquely identifying users? Am I missing something? (probably).
Perspective correction is required because simple (2d-linear) texture mapping fails to take into account the effect of distance over the surface of a texture. For instance, mapping a checkerboard texture onto the 2d projection of a piece of ground results in an image where the lines in the grid fail to get closer together the further away they are.
The PlayStation 1 did not have perspective correction, and had to compensate by slicing polys into smaller pieces when they got closer to the viewpoint, thus helping to minimise the perspective artifacts.
Of course, every console since the N64 has had perspective correction - this is such a standard feature nowadays (as is Z-buffering!) that it's hardly worth mentioning. The fact that they do mention it is a little worrying.
Actually, the same could be said about gouraud-shading and alpha-blending too! This feature list is pretty basic stuff.
As others have pointed out, there is a world of difference between videogame programming and design.
If you think you have (or can develop) the technical skills to become a games programmer, then I'd strongly suggest you take that route. The fact is that the demand for programmers is so much higher than for designers - a good games designer is worth a great deal, but there are simply many more of them out there.
There's also a misconception that a games designer spends much of his/her time coming up with new ideas for games - not so. Ideas for games realy are two-a-penny - implementation is what's important. The vast majority of the games designer's responsibility is in areas such as level layout, AI script tweaking, etc... etc...
If you're a reasonably competent programmer, then there are any number of books to get you started (eg. Tricks of the Game Programming Gurus, Game Programming Gems). However, in my experience (been programming in the games industry for 8 years), the best programmers are the ones who teach themselves. I did a 3 year computer science degree, but didn't learn anything games-related directly. It did, however, give me 3 years during which I didn't have to worry about getting a job, and was therefore able to play around with hand optimised assembly. Most of my game development skills at the time came from downloading demos, and trying to figure out how the hell the latest effect worked.
If, on the other hand, you're more comfortable with game design, then a near encyclopaedic knowledge of videogames is pretty much a must. Be able to describe exactly what it is about your favourite game that makes it more fun to play than the others - gameplay is almost a mystical, intangible quantity - one that is highly sought after. Be able to compare and contrast games in the same genre, and identify what you think the strengths and weaknesses of each are.
Anyway, best of luck - it's one of the best industries to be in - if also one of the most demanding.
I'd heard that there are similar numbers of minutes of commercial airtime per hour between the US and UK.
I find this really hard to believe. The commercial breaks certainly didn't seem any longer - 2/3 minutes at the most. A half hour show would have a single commercial break half-way through. Whether things have changed that much since then, I don't know. I remember being astonished on moving to the USA for the first time, and discovering that there are commercial breaks immediately after the opening credits!.
When I lived in England, we had to pay an annual "license fee" - when I was last there it was approximately $150 per year. This provided 2 channels of commercial-free television. The other two channels had ads, but far, far fewer than any US station.
Now I live in Los Angeles, and pay around $600 per year for the privelege of watching a seemingly non-stop series of commercials. My only consolation (and that which keeps me paying the cable bill) is the occasional Simpsons episode.
Even with 4 TV stations, there was still a greater range of quality programs available than with the 80 or so I have today.
Yes, I know this is more of a rant than a constructive comment about TiVo, but frankly, I feel that I've paid the cable companies enough already.
2. A NAT gateway's functionality needs to be extended to handle the AVES protocols. This can be achieve by running an additional software program called the AVES NAT Daemon
on the NAT gateway device. The AVES NAT Daemon does not alter the pre-existing functionality of the NAT gateway.
A few points. First off, if you're able to mess with your gateway's software, why not just use SOCKS, which has been around for much longer, and, I believe, can be configured to provide the same functionality.
Secondly, the majority of NATs out there (I'm talking about home DSL/cable connection sharing NATs here) don't allow you to install new protocols of your choosing!
Thirdly, there are much better ways of doing this that don't even require you to mess with your NAT router. (1) NAT user (A) connects to 3rd party connection-broker server, and registers. Since NATs happily allow outgoing connections, this is fine. (2) User B wishes to connect to NAT user. Opens a TCP port for listening. Sends a request to A's broker server, including the listening port number. (3) Broker sends message back down established TCP channel to (A) saying "B wants to connect - here's B's open TCP port number". (4) A makes outgoing connection to B. (5) A and B have a TCP connection, and live happily ever after.
This only works when one user is non-NAT'd. There are similar techniques for establishing UDP connections where both users are NAT'd, and I came up with a (ugly!) way of establishing a full TCP connection two NAT'd TCP users, using a 3rd party only during the connection brokering stage. Click here for info. Unfortunately, since MS's TCP stack is buggy, this technique fails when the machines are Windows boxes. GRRRR!
Heh... the page on Psygnosis certainly rings true. I worked there for a few years up to '96, at which point there were roughly 30 people in our office (not the Liverpool one). About a year after I left, I went back to visit, and found about 80-100 people working there. Clearly, they had moved well beyond the point where everyone knew each other on a first name basis. (One of my former colleagues told me that the guy who he had initially thought was there to fix the heating turned out to be a second-line manager or something).
Needless to say, after hiring so many suits, and failing to put out enough quality titles, the implosion was almost as spectacular as the explosion.
Those are both good suggestions, however, once again, there's the trade-off between security and useability. For instance, I can't admin remotely with your scheme.
As for "Make sure all your daemons aren't grossly insecure"... well, that's rather the point, isn't it?! A bit like saying "If you're worried about security, then just make your box secure" - strictly speaking, correct, but not terribly useful.
There is a great deal of argument about whose OS is more "secure".
It is true that both systems can be well secured if the sysadmin knows what he/she is doing, keeps up with the latest patches, and keeps a wary eye open for attacks.
It is also true that an inexperienced sysadmin can use either OS to create a box that is dangerously insecure.
So, why do I believe that Linux will always have a security advantage over NT? Because the source code is available for anyone to look at. Exploits are found, and sometimes... err... exploited! But - the most important thing is that they're located, and fixed!. Linux is equipped to deal with potential problems very quickly, due to the sheer number of people combing through the code. Microsoft (and any closed-source developer) simply do not have the required number of people to check their code for vulnerabilities. This means that weaknesses can only be located and fixed by a small number of people. Yes, it also means that it's harder for crackers to find exploits, but, as the last couple of years have shown, they've still managed admirably.
Security is not a quantity - it's a process, and Linux moves faster.
This doesn't apply to just security problems, but also to bugs in general. We notified MS about a bug in their TCP implementation some time ago. All we can do is twiddle our thumbs while we wait for a fix (which may never arrive). If their stack were open-sourced, we could identify the offending line of code, and come up with a fix ourselves, which we could then submit for approval, thus speeding things up no end.
A huge proportion of spam that I receive arrives at my mail server from foreign machines, but more often than not, the foreign machines are merely open SMTP relays that have been used to try and obscure the original source - (usually a UUNET dialup customer), in addition to using a forged From: field.
Even if the spam originates from a foreign machine, the service they're offering is quite often located in the US. If they advertise a website, or the spam includes a submission form, it's relatively easy to locate the ISP that's hosting the spammer's site. Quite frequently, this is a violation the ISP's AUP, and a notification to the ISP will result in the spammer's site being removed (thus all their spamming efforts were wasted!).
There are utilities such as spamcop which are designed to assist in identifying the true source of junk emails. I generally do things by hand (traceroute, etc...), so I can't say whether or not spamcop is any good - just thought I'd mention that it exists.
However, since you can't receive data from the spoofed connection, you're not going to be able to read files.
Now, let's suppose Joe Stupid has made his entire drive writeable, using source IP address for authentication. Well, then he has problems - but, his machine would still need to be visible to the outside world - ie. connected directly to the internet without a firewall/whatever. And the attacker would need to know exactly how to carry out a SMB conversation without being able to receive any responses from the target computer!.
Regardless of all this, if Joe Stupid has his PC connected directly to the internet, with a fully writeable hard drive, ISN prediction is the least of his problems:)
Well... let's assume someone was able to predict the ISN's coming from your WinGate machine. That way, they could impersonate a machine inside your LAN (but only send data, not receive it!).
In terms of breaking into your LAN, they're still no better off than they were before (going on the prior assumption that there are no other services running on your internal machines that only use source IP for authentication) - in fact, the absolute worst thing they could do would be to use Wingate to make an outgoing connection to the internet that looks like it's coming from you. Since they wouldn't be able to receive any data from this connection, it would be of limited value in hacking.
Frankly, I'd love a replacement for WinGate that ran on linux.
There is such a thing - it's called Linux!:)
Linux has NAT (IP masquerading) built into the kernel - it does everything Wingate can do, and much, much more. It's a whole load more configurable! I use it all the time.
In order to hijack a TCP connection, you have to sniff packets prior to taking control. In order to do this, you must be in a position such that you are able to intercept traffic between the two machines. Generally, this would entail being on the same LAN as the victim, or the machine he's logged into.
So, what does ISN prediction actually enable you to do? Well, it allows you to form a TCP connection to a remote machine (X) that looks to X like it's coming from a 3rd machine (Y) instead of yours (A). Note also that this connection is one way - you can send information down it, but you don't get anything back. This is only useful as an exploit if (1) The machine you're talking to (X) is prepared to grant the 3rd machine (Y) special privileges, based solely on Y's IP address - in other words, a "trust" relationship exists between X and Y exists, and (2) The exploit doesn't require you to receive data back from X, and (3) The service you're connecting to on X doesn't require any additional password authentication.
Many version of Unix ship with the rsh suite of services enabled by default. These services can be dangerous, because they can be configured to meet all of the criteria described above. However, most Unix TCP stacks employ fairly decent ISN randomisation, and thus are exceedingly tricky to exploit in this manner. (Mitnick's famous breakin to Shimomura's machines relied on rsh being available, and Shimomura running a TCP stack with no ISN randomisation to speak of.)
On the other hand, Win98 has shockingly predictable ISN's. However, Win98 doesn't run rsh. In fact, Win98 doesn't run any services (that I'm aware of - someone please correct me if I'm mistaken) that (a) use source IP as an authenticator and (b) don't have some other kind of password protection.
So, really, this isn't going to be too much of a problem.
Assuming that the attacked machine is on an internal LAN, and that the trusted machine being impersonated is on the same subnet, you could certainly detect that the packets are being sent to you from the wrong MAC address (you would be receiving packets from LAN's gateway MAC, not the MAC of the machine being impersonated). That would alert you to something being awry.
However, using MAC addresses for authentication only works if you don't decide to switch network cards. A far better solution is for the router/firewall to be intelligent enough to recognise that the incoming packet (coming from the Internet) has a source IP corresponding to a machine inside the firewall, and thus something's wrong. Many routers can be configured to discard such spoofed packets.
I'd like to make a further point, which a lot of people seem to be missing...
Yes, ISN-prediction enables spoofed TCP connections to be established. However, this is not the real problem. The problem is the use of protocols (rsh, rcmd) that rely solely on source-IP address for authentication.
The first thing I do when installing Linux is to disable rsh, rcmd, etc... You should never allow someone to execute root privilege commands just because they appear to be coming from a particular IP address.
A further point... so Winsock has easily predictable ISN's - big surprise. However, (correct me if I'm mistaken), but next to no-one runs rsh on Windows boxes, right? Exactly which TCP services is this exploit going to help you with on a Windows box? Does Windows provide services that are based only on source IP for authentication?
I'm not defending MS's crappy Winsock stack - it has a number of worse problems than this - but I think that the value of this exploit has been greatly exaggerated.
Two questions - 1) if this "problem" has been around since the mid-80's why has it never been exploited?
Actually, according to Shimomura's rather self-obsessed book "Takedown", this is one of the attacks that Mitnick used to exploit the trust relationship between two of Shimomura's machines.
Anyway, this really is old news... these days, a good OS generates randomness based on extremely unpredictable external values, such as the number of microseconds the hard drive took to read the last sector, for example - thus rendering a hacker pretty much helpless to predict the next ISN.
The main use for ISN prediction as a hacking tool is to spoof TCP packets such that they appear to be coming from a trusted source IP address. Although this problem has been adressed in all worthwhile TCP stacks, it is still bad practice to rely solely on source IP as an authentication method.
Strags
Doesn't work for all NAT's, unfortunately. Some NAT implementations will only allow incoming UDP packets where the source ip/port match a host that you already sent a packet to (rather like a connected UDP socket). Any other packets are discarded. The sad fact is, there is no trivial solution that works under *every* circumstance.
While the premise certainly is interesting, I doubt these guys will get anywhere. The site appears to be run more by marketing types than techies. They've already devoted more web space to the marketing/advertising opportunities than they have to any of the technical issues.
I'm sure they've already started focus group testing...
I guess you missed the other thread...
Multicasting is no good for file transfer - imagine streaming simultaneously from a single source to 2 users, one with a 56K modem, the other with a T3. Doesn't work, does it?
Multicasting is generally used for streaming video/audio, where you don't expect to catch every packet - video/audio streams don't have to have 100% integrity to be legible. Data does.
I would assume that his link would have to be explicitly labelled as pointing to DeCSS in some way for any liability.
Granted, the wording of (2) as it stands is far stronger, but I'd like to see them try and uphold it under the circumstances you describe.
Slashdot Mirror
14. Can the 64-bit version of Windows Whistler read, write, and boot from MBR disks?
The 64-bit version of Windows Whistler can read and write MBR disks, but cannot boot from MBR disks.
15. Can the 32-bit version of Windows Whistler read, write, and boot from GPT disks?
No. The 32-bit version will see only the Protective MBR. The EE partition will not be mounted or otherwise exposed to application software.
16. Can the 32-bit version of Windows Whistler read, write, and boot from MBR disks?
Yes.
So this really applies only to the 64-bit version - the 32-bit version won't even support GPT drives.
55. Is it possible to make a sector-by-sector copy of a GPT disk?
No. The Disk and Partition GUIDs will no longer be unique. This must never happen. You can make a sector-by-sector copy of the contents of ESP or basic data partitions.
Perhaps I misunderstand - I assumed the the GUIDS would be unique per installed OS, not unique per user. What possible reason could there be for this other than uniquely identifying users? Am I missing something? (probably).
Perspective correction is required because simple (2d-linear) texture mapping fails to take into account the effect of distance over the surface of a texture. For instance, mapping a checkerboard texture onto the 2d projection of a piece of ground results in an image where the lines in the grid fail to get closer together the further away they are.
The PlayStation 1 did not have perspective correction, and had to compensate by slicing polys into smaller pieces when they got closer to the viewpoint, thus helping to minimise the perspective artifacts.
Of course, every console since the N64 has had perspective correction - this is such a standard feature nowadays (as is Z-buffering!) that it's hardly worth mentioning. The fact that they do mention it is a little worrying.
Actually, the same could be said about gouraud-shading and alpha-blending too! This feature list is pretty basic stuff.
As others have pointed out, there is a world of difference between videogame programming and design.
If you think you have (or can develop) the technical skills to become a games programmer, then I'd strongly suggest you take that route. The fact is that the demand for programmers is so much higher than for designers - a good games designer is worth a great deal, but there are simply many more of them out there.
There's also a misconception that a games designer spends much of his/her time coming up with new ideas for games - not so. Ideas for games realy are two-a-penny - implementation is what's important. The vast majority of the games designer's responsibility is in areas such as level layout, AI script tweaking, etc... etc...
If you're a reasonably competent programmer, then there are any number of books to get you started (eg. Tricks of the Game Programming Gurus, Game Programming Gems). However, in my experience (been programming in the games industry for 8 years), the best programmers are the ones who teach themselves. I did a 3 year computer science degree, but didn't learn anything games-related directly. It did, however, give me 3 years during which I didn't have to worry about getting a job, and was therefore able to play around with hand optimised assembly. Most of my game development skills at the time came from downloading demos, and trying to figure out how the hell the latest effect worked.
If, on the other hand, you're more comfortable with game design, then a near encyclopaedic knowledge of videogames is pretty much a must. Be able to describe exactly what it is about your favourite game that makes it more fun to play than the others - gameplay is almost a mystical, intangible quantity - one that is highly sought after. Be able to compare and contrast games in the same genre, and identify what you think the strengths and weaknesses of each are.
Anyway, best of luck - it's one of the best industries to be in - if also one of the most demanding.
I'd heard that there are similar numbers of minutes of commercial airtime per hour between the US and UK.
I find this really hard to believe. The commercial breaks certainly didn't seem any longer - 2/3 minutes at the most. A half hour show would have a single commercial break half-way through. Whether things have changed that much since then, I don't know. I remember being astonished on moving to the USA for the first time, and discovering that there are commercial breaks immediately after the opening credits!.
When I lived in England, we had to pay an annual "license fee" - when I was last there it was approximately $150 per year. This provided 2 channels of commercial-free television. The other two channels had ads, but far, far fewer than any US station.
Now I live in Los Angeles, and pay around $600 per year for the privelege of watching a seemingly non-stop series of commercials. My only consolation (and that which keeps me paying the cable bill) is the occasional Simpsons episode.
Even with 4 TV stations, there was still a greater range of quality programs available than with the 80 or so I have today.
Yes, I know this is more of a rant than a constructive comment about TiVo, but frankly, I feel that I've paid the cable companies enough already.
2. A NAT gateway's functionality needs to be extended to handle the AVES protocols. This can be achieve by running an additional software program called the AVES NAT Daemon on the NAT gateway device. The AVES NAT Daemon does not alter the pre-existing functionality of the NAT gateway.
A few points. First off, if you're able to mess with your gateway's software, why not just use SOCKS, which has been around for much longer, and, I believe, can be configured to provide the same functionality.
Secondly, the majority of NATs out there (I'm talking about home DSL/cable connection sharing NATs here) don't allow you to install new protocols of your choosing!
Thirdly, there are much better ways of doing this that don't even require you to mess with your NAT router. (1) NAT user (A) connects to 3rd party connection-broker server, and registers. Since NATs happily allow outgoing connections, this is fine. (2) User B wishes to connect to NAT user. Opens a TCP port for listening. Sends a request to A's broker server, including the listening port number. (3) Broker sends message back down established TCP channel to (A) saying "B wants to connect - here's B's open TCP port number". (4) A makes outgoing connection to B. (5) A and B have a TCP connection, and live happily ever after.
This only works when one user is non-NAT'd. There are similar techniques for establishing UDP connections where both users are NAT'd, and I came up with a (ugly!) way of establishing a full TCP connection two NAT'd TCP users, using a 3rd party only during the connection brokering stage. Click here for info. Unfortunately, since MS's TCP stack is buggy, this technique fails when the machines are Windows boxes. GRRRR!
Heh... the page on Psygnosis certainly rings true. I worked there for a few years up to '96, at which point there were roughly 30 people in our office (not the Liverpool one). About a year after I left, I went back to visit, and found about 80-100 people working there. Clearly, they had moved well beyond the point where everyone knew each other on a first name basis. (One of my former colleagues told me that the guy who he had initially thought was there to fix the heating turned out to be a second-line manager or something).
Needless to say, after hiring so many suits, and failing to put out enough quality titles, the implosion was almost as spectacular as the explosion.
Those are both good suggestions, however, once again, there's the trade-off between security and useability. For instance, I can't admin remotely with your scheme.
As for "Make sure all your daemons aren't grossly insecure"... well, that's rather the point, isn't it?! A bit like saying "If you're worried about security, then just make your box secure" - strictly speaking, correct, but not terribly useful.
Strags
There is a great deal of argument about whose OS is more "secure".
... err ... exploited! But - the most important thing is that they're located, and fixed!. Linux is equipped to deal with potential problems very quickly, due to the sheer number of people combing through the code. Microsoft (and any closed-source developer) simply do not have the required number of people to check their code for vulnerabilities. This means that weaknesses can only be located and fixed by a small number of people. Yes, it also means that it's harder for crackers to find exploits, but, as the last couple of years have shown, they've still managed admirably.
It is true that both systems can be well secured if the sysadmin knows what he/she is doing, keeps up with the latest patches, and keeps a wary eye open for attacks.
It is also true that an inexperienced sysadmin can use either OS to create a box that is dangerously insecure.
So, why do I believe that Linux will always have a security advantage over NT? Because the source code is available for anyone to look at. Exploits are found, and sometimes
Security is not a quantity - it's a process, and Linux moves faster.
This doesn't apply to just security problems, but also to bugs in general. We notified MS about a bug in their TCP implementation some time ago. All we can do is twiddle our thumbs while we wait for a fix (which may never arrive). If their stack were open-sourced, we could identify the offending line of code, and come up with a fix ourselves, which we could then submit for approval, thus speeding things up no end.
Strags
A huge proportion of spam that I receive arrives at my mail server from foreign machines, but more often than not, the foreign machines are merely open SMTP relays that have been used to try and obscure the original source - (usually a UUNET dialup customer), in addition to using a forged From: field.
Even if the spam originates from a foreign machine, the service they're offering is quite often located in the US. If they advertise a website, or the spam includes a submission form, it's relatively easy to locate the ISP that's hosting the spammer's site. Quite frequently, this is a violation the ISP's AUP, and a notification to the ISP will result in the spammer's site being removed (thus all their spamming efforts were wasted!).
There are utilities such as spamcop which are designed to assist in identifying the true source of junk emails. I generally do things by hand (traceroute, etc...), so I can't say whether or not spamcop is any good - just thought I'd mention that it exists.
Strags
However, since you can't receive data from the spoofed connection, you're not going to be able to read files.
:)
Now, let's suppose Joe Stupid has made his entire drive writeable, using source IP address for authentication. Well, then he has problems - but, his machine would still need to be visible to the outside world - ie. connected directly to the internet without a firewall/whatever. And the attacker would need to know exactly how to carry out a SMB conversation without being able to receive any responses from the target computer!.
Regardless of all this, if Joe Stupid has his PC connected directly to the internet, with a fully writeable hard drive, ISN prediction is the least of his problems
Strags
Well... let's assume someone was able to predict the ISN's coming from your WinGate machine. That way, they could impersonate a machine inside your LAN (but only send data, not receive it!).
:)
In terms of breaking into your LAN, they're still no better off than they were before (going on the prior assumption that there are no other services running on your internal machines that only use source IP for authentication) - in fact, the absolute worst thing they could do would be to use Wingate to make an outgoing connection to the internet that looks like it's coming from you. Since they wouldn't be able to receive any data from this connection, it would be of limited value in hacking.
Frankly, I'd love a replacement for WinGate that ran on linux.
There is such a thing - it's called Linux!
Linux has NAT (IP masquerading) built into the kernel - it does everything Wingate can do, and much, much more. It's a whole load more configurable! I use it all the time.
Strags
Firstly, ISN prediction is not telnet hijacking.
In order to hijack a TCP connection, you have to sniff packets prior to taking control. In order to do this, you must be in a position such that you are able to intercept traffic between the two machines. Generally, this would entail being on the same LAN as the victim, or the machine he's logged into.
So, what does ISN prediction actually enable you to do? Well, it allows you to form a TCP connection to a remote machine (X) that looks to X like it's coming from a 3rd machine (Y) instead of yours (A). Note also that this connection is one way - you can send information down it, but you don't get anything back. This is only useful as an exploit if (1) The machine you're talking to (X) is prepared to grant the 3rd machine (Y) special privileges, based solely on Y's IP address - in other words, a "trust" relationship exists between X and Y exists, and (2) The exploit doesn't require you to receive data back from X, and (3) The service you're connecting to on X doesn't require any additional password authentication.
Many version of Unix ship with the rsh suite of services enabled by default. These services can be dangerous, because they can be configured to meet all of the criteria described above. However, most Unix TCP stacks employ fairly decent ISN randomisation, and thus are exceedingly tricky to exploit in this manner. (Mitnick's famous breakin to Shimomura's machines relied on rsh being available, and Shimomura running a TCP stack with no ISN randomisation to speak of.)
On the other hand, Win98 has shockingly predictable ISN's. However, Win98 doesn't run rsh. In fact, Win98 doesn't run any services (that I'm aware of - someone please correct me if I'm mistaken) that (a) use source IP as an authenticator and (b) don't have some other kind of password protection.
So, really, this isn't going to be too much of a problem.
Strags
Assuming that the attacked machine is on an internal LAN, and that the trusted machine being impersonated is on the same subnet, you could certainly detect that the packets are being sent to you from the wrong MAC address (you would be receiving packets from LAN's gateway MAC, not the MAC of the machine being impersonated). That would alert you to something being awry.
However, using MAC addresses for authentication only works if you don't decide to switch network cards. A far better solution is for the router/firewall to be intelligent enough to recognise that the incoming packet (coming from the Internet) has a source IP corresponding to a machine inside the firewall, and thus something's wrong. Many routers can be configured to discard such spoofed packets.
Strags
I'd like to make a further point, which a lot of people seem to be missing...
Yes, ISN-prediction enables spoofed TCP connections to be established. However, this is not the real problem . The problem is the use of protocols (rsh, rcmd) that rely solely on source-IP address for authentication.
The first thing I do when installing Linux is to disable rsh, rcmd, etc... You should never allow someone to execute root privilege commands just because they appear to be coming from a particular IP address.
A further point... so Winsock has easily predictable ISN's - big surprise. However, (correct me if I'm mistaken), but next to no-one runs rsh on Windows boxes, right? Exactly which TCP services is this exploit going to help you with on a Windows box? Does Windows provide services that are based only on source IP for authentication?
I'm not defending MS's crappy Winsock stack - it has a number of worse problems than this - but I think that the value of this exploit has been greatly exaggerated.
Strags
Two questions - 1) if this "problem" has been around since the mid-80's why has it never been exploited? Actually, according to Shimomura's rather self-obsessed book "Takedown", this is one of the attacks that Mitnick used to exploit the trust relationship between two of Shimomura's machines. Anyway, this really is old news... these days, a good OS generates randomness based on extremely unpredictable external values, such as the number of microseconds the hard drive took to read the last sector, for example - thus rendering a hacker pretty much helpless to predict the next ISN. The main use for ISN prediction as a hacking tool is to spoof TCP packets such that they appear to be coming from a trusted source IP address. Although this problem has been adressed in all worthwhile TCP stacks, it is still bad practice to rely solely on source IP as an authentication method. Strags
Doesn't work for all NAT's, unfortunately. Some NAT implementations will only allow incoming UDP packets where the source ip/port match a host that you already sent a packet to (rather like a connected UDP socket). Any other packets are discarded. The sad fact is, there is no trivial solution that works under *every* circumstance.
While the premise certainly is interesting, I doubt these guys will get anywhere. The site appears to be run more by marketing types than techies. They've already devoted more web space to the marketing/advertising opportunities than they have to any of the technical issues. I'm sure they've already started focus group testing...
I guess you missed the other thread... Multicasting is no good for file transfer - imagine streaming simultaneously from a single source to 2 users, one with a 56K modem, the other with a T3. Doesn't work, does it? Multicasting is generally used for streaming video/audio, where you don't expect to catch every packet - video/audio streams don't have to have 100% integrity to be legible. Data does.
I would assume that his link would have to be explicitly labelled as pointing to DeCSS in some way for any liability. Granted, the wording of (2) as it stands is far stronger, but I'd like to see them try and uphold it under the circumstances you describe.