The "Full Raw Socket" debate...

I'd have to agree with your assessment 8Ball. Both sides of this particular coin are just media hogs. Gibson was trying to garner attention by making it such an issue, and whomever runs grcsucks.com was just attempting to piggyback on that attention by spinning their own version of things. Both sides ignore very critical facts, such as the one you pointed out in your post. I do think Gibson is correct in one area though: Microsoft DOES NOT understand security.





If you give it time, we'll start seeing viruses that use SYN floods with source IPs that randomize every few minutes probably in the next 18-24 months if I had to guess, unless XP really doesn't sell well. Code red was almost a warning shot. Imagine code red but instead of the lame DDoS it was attempting to use, it's armed with SYN flooding capability and source IP control that lets it change the source IP of the host every few minutes. Some fine tuning and a large base of XP Home Edition users would be all that's needed to make a virus that could quite literally shut down large sections of the 'net.



We'll just have to wait and see what happens, I suppose.

ya....add in theregister.com to the media hogs. i saw some stuff written by one of the guys there...lets just say almost as stupid as that "worst windows virus ever!" thread. i have to say that i lean more twards gibson's side than his oposition....99% of the arguements against him consist of nothing more than nitpicking spefic things he said rather than debating the actual issue...stuff like "he shows a picture of a programs hex code and the third number from the left in the thirtyith row is off by one number so he is obviously a total idiot and you should worship me for exposing him"

as i said above, however, gibson ignores several important issues. my opnion would be that he is at the learning stage with this stuff even tho he knows alot of other stuff quite well. as we all know alot of knoledge can be dangerious, but just a little of knoledge is deadly.

Speaking of Syn floods... I wonder if they'll include a service-pack thingy (if it isn't already there) to XP that would allow you to set Syn timeouts, such as a level of 'patience' with hosts trying to start an incoming TCP connection. That way, if you aren't running a server, you could give incoming connections a really low timeout, since it's likely you don't care much about people trying to connect to you.

I guess what I mean is that a syn flood is primarily a denial to others of a server. If you aren't concerned with being acessible to others who initiate contact via TCP, then it wouldn't be so damaging for your system to drop incoming TCP connections due to currently waiting for a ton of secondary SYNs.

From what I've read, this basically boils down to that programs on XP machines can do a lot more in terms of crafting packets, without relying on VXDs and many fancy-shmansy low-level modifications and additions, right? And that XP will be using (*nix-like) Berkeley sockets as opposed to ye olde Winsock?

I'm not very clear, personally, on the conflict. Is it that it just makes it easier for people to make programs that do socket/packet hyjinx? Well, that can be a great good or great evil. But it also might make it easier to craft programs designed to detect and curb Evil-Little-Viruses-&-Worms™.

Quote:

---

Originally posted by Terr
I'm not very clear, personally, on the conflict. Is it that it just makes it easier for people to make programs that do socket/packet hyjinx? Well, that can be a great good or great evil. But it also might make it easier to craft programs designed to detect and curb Evil-Little-Viruses-&-Worms™.

---

Well, I don't know the ins and outs of writing low-level networking code under XP, but from everything I've read there is absolutely no reason to allow anyone other than the 'system' account access to edit packets at their leisure. Basically, from what I've read, NAT doesn't even require that kind of access, and modifying the source IP/dest IP in the packets is basically what it does.