I'm not sure what you're getting at. I didn't say anything about HOW you should configure your DNS on your Mac, I merely pointed out that the client itself is not behaving like a recursive DNS server and thus is not exposed to this particular attack.
Changing the details of how the client DNS resolver selects ports and sequence numbers won't make any difference at all if your upstream is exposed.
But I would be surprised to see a recursive DNS server in a home firewall/router. Mine just provides via DHCP whatever it gets via DHCP from the ISP, rather than adding the substantial overhead of an additional and unnecessary application.
The iPhone is designed to be used as a Treo or iPaq running any software you can create for it, unrestricted. it's not a "pocket mac" or even the new Newton. It may become that, eventually, but if you're buying one expecting it to be anything but a really good cellphone with Internet access, you're buying the wrong product.
And on top of that...
As long as it's got unlimited cellular data services for a fixed rate, you're not going to get an unlocked unrestricted iPhone. That's an obvious tradeoff... if you're getting unlimited cellular data service, you're going to be limited on how you can use it, and tethering your cellphone to a general purpose computer is way beyond anything they can afford to allow.
If there's an attacker on the public wifi with you who can use this attack on you, then they have already used something like an ICMP redirect spoofing attack to get you using them as the upstream router, and they can see and modify every packet you send and receive... so they don't need to *guess* the magic numbers you're using: you're giving them to them anyway.
So you're saying that on Leopard the resolver ignores the DNS server settings you give it (regardless of how you give them to it, or what database it stores them in) and goes groveling around doing name resolution starting at a.root-servers.net and working down?
Because unless the client resolver does something daft like that (and, yes, that would be daft, and a bug in Leopard) the result is the same as if it was still using lookupd: the requests would have to be sniffed for a potential attacker to get a transaction or port number to use in the attack, and if the attacker is in a position to do that they don't need to predict the numbers, they just have to respond quicker than the real nameserver.
The issue is that if you're using your macbook at Starbucks, that local LAN you're on is suspect.
If the local LAN is suspect you've already lost. That was proven when a bunch of fellows sniffed a bunch of security researcher's passwords on the Wifi at Usenix a while back.
Spoof the IP, brute force the transaction number, and get the client to perform lookups for names you already know, and you can convince it that YOU are the upstream server.
If you're in a position to read any transaction number from the client so you can brute-force the next one, you have to be able to sniff it anyway, and you don't NEED to brute-force it, you just need to be able to respond faster than the actual name server.
And since you're on the same LAN or at least closer to the nameserver than the client is, you're in a good position to do that.
The reason that this class of attack works against nameservers is that with a recursive nameserver you can get the nameserver to send you a packet that you can use to guess the sequence from. You can't do that with a client-only nameserver.
Unless lookupd is doing something really weird, this is a non-issue.
Lookupd only talks to the nameservers specified by the settings in netinfo, provided by DHCP, and possibly flat files. Unless your immediate upstream nameserver isn't recursive (which is really stupid) or it is compromised there's no mechanism to get lookupd to query any other nameservers.
Which means that unless the attacker is on the local LAN there's no mechanism to see the queries.
And if he is then this is the least of your worries.
I currently pay a monthly fee to my association and it covers lawn care, water, sewer, snow removal and garbage removal.
Me too. It also pays for them to dig a hole in my yard, not fill it in, then send me a nasty notice threatening me with fines if I don't fix the hole in my yard. Depending on them for Internet access, too? God almighty!
Fiber is a backhoe magnet. If the homeowners are responsible for the last mile, who's responsible for repairing it when the inevitable backhoe strikes? The neighborhood association? Heaven forfend!
i would hate to see how bad it gets when you have people with Down Syndrome download the open source client and then calling blizzard saying "I download the source but i can't get wow to run, what? what do you mean i have to compile it. whats that? why doesnt this work right now, blizzard help plz!!"
Helpdesk: "Dude, you're only a level 0 hacker, if you try and use the open source client before you're at LEAST level 7 and have the Visual Studio skill it's gonna aggro your compiler. You don't want to do that, it's not pretty."
In this message in 1983 a troll who used the pseudonym "Elizabeth Bimmler" started the first major trolling campaign on Usenet, attacking the group net.suicide (a support group for depression). The same group created a semi-automated trolling program under the name Mark V. Shaney. There has been a lot of mythology built up about these campaigns, probably because the person primarily responsible is a well known and respected member of the UNIX establishment, but really they're no different in nature from what the/b/tards do today.
My Macbook Pro has horrible thermal problems, and I'm using a third party program to take over my fan control to keep it cool... and mine's got an ATI GPU.
If Blizzard is selling a user interface (the client) then they shouldn't care who's improving the user interface.
If Blizzard is selling a service, then they shouldn't be implementing the security in the client: you can't stop anyone breaking in to their own computer.
What costs more, the service or the client?
Open source the part that you're not making money from, and quit worrying about Glider.
Y'all think I'm kidding? Y'all think this is flamebait?
I'm not. It's not. I'm serious. You can't stop people breaking in to their own computers. If you want to implement the security at the client, make the game run on a console.
I have a huge reliance on my PDA, which has had a huge effect on handling my organizational issues. So should I go back to being as disorganized as I used to be, instead of being the guy who does the organization? I'm just as dependent on my PDA as Steve Mann was on his Wearcam. If you use a cellphone or an addess book or a paper organizer, well, you have the same problem. This isn't a new problem, it's not a high tech problem, I'm sure Himuralabima of Babylon would have found himself just as lost without his clay tablets and stylus as I would without my PDA and stylus... heck, my PDA is almost exactly the same size and shape as his clay tablets.
In Charlie Stross's Accelerando, in Chapter 3, Manfred Manx loses his wearable and the result is, well, not good for a while. But all ends well...
Refusing to use a tool because you'll become dependent on it is only a problem if you plan on stopping using it. Steve Mann decided he was engaged in an experiment. For some of us, electronic memory aids from PDAs and Google on up are a lifestyle, not an experiment.
They really need to just open source the Warcraft client. If the user interface is reducing the fun of the game by forcing people to repeat pointless activities, let the open source community fix the interface... and implement security at the server.
I stuck out my contract with Sprint because I was bloody well determined NOT to pay their damn termination fee. Pity this decision hadn't happened a year or so sooner.
Slashdot Mirror
I'm not sure what you're getting at. I didn't say anything about HOW you should configure your DNS on your Mac, I merely pointed out that the client itself is not behaving like a recursive DNS server and thus is not exposed to this particular attack.
Changing the details of how the client DNS resolver selects ports and sequence numbers won't make any difference at all if your upstream is exposed.
But I would be surprised to see a recursive DNS server in a home firewall/router. Mine just provides via DHCP whatever it gets via DHCP from the ISP, rather than adding the substantial overhead of an additional and unnecessary application.
The iPhone is designed to be used as a Treo or iPaq running any software you can create for it, unrestricted. it's not a "pocket mac" or even the new Newton. It may become that, eventually, but if you're buying one expecting it to be anything but a really good cellphone with Internet access, you're buying the wrong product.
And on top of that...
As long as it's got unlimited cellular data services for a fixed rate, you're not going to get an unlocked unrestricted iPhone. That's an obvious tradeoff... if you're getting unlimited cellular data service, you're going to be limited on how you can use it, and tethering your cellphone to a general purpose computer is way beyond anything they can afford to allow.
If there's an attacker on the public wifi with you who can use this attack on you, then they have already used something like an ICMP redirect spoofing attack to get you using them as the upstream router, and they can see and modify every packet you send and receive... so they don't need to *guess* the magic numbers you're using: you're giving them to them anyway.
So you're saying that on Leopard the resolver ignores the DNS server settings you give it (regardless of how you give them to it, or what database it stores them in) and goes groveling around doing name resolution starting at a.root-servers.net and working down?
Because unless the client resolver does something daft like that (and, yes, that would be daft, and a bug in Leopard) the result is the same as if it was still using lookupd: the requests would have to be sniffed for a potential attacker to get a transaction or port number to use in the attack, and if the attacker is in a position to do that they don't need to predict the numbers, they just have to respond quicker than the real nameserver.
The issue is that if you're using your macbook at Starbucks, that local LAN you're on is suspect.
If the local LAN is suspect you've already lost. That was proven when a bunch of fellows sniffed a bunch of security researcher's passwords on the Wifi at Usenix a while back.
Spoof the IP, brute force the transaction number, and get the client to perform lookups for names you already know, and you can convince it that YOU are the upstream server.
If you're in a position to read any transaction number from the client so you can brute-force the next one, you have to be able to sniff it anyway, and you don't NEED to brute-force it, you just need to be able to respond faster than the actual name server.
And since you're on the same LAN or at least closer to the nameserver than the client is, you're in a good position to do that.
The reason that this class of attack works against nameservers is that with a recursive nameserver you can get the nameserver to send you a packet that you can use to guess the sequence from. You can't do that with a client-only nameserver.
Unless lookupd is doing something really weird, this is a non-issue.
Lookupd only talks to the nameservers specified by the settings in netinfo, provided by DHCP, and possibly flat files. Unless your immediate upstream nameserver isn't recursive (which is really stupid) or it is compromised there's no mechanism to get lookupd to query any other nameservers.
Which means that unless the attacker is on the local LAN there's no mechanism to see the queries.
And if he is then this is the least of your worries.
I currently pay a monthly fee to my association and it covers lawn care, water, sewer, snow removal and garbage removal.
Me too. It also pays for them to dig a hole in my yard, not fill it in, then send me a nasty notice threatening me with fines if I don't fix the hole in my yard. Depending on them for Internet access, too? God almighty!
Fiber is a backhoe magnet. If the homeowners are responsible for the last mile, who's responsible for repairing it when the inevitable backhoe strikes? The neighborhood association? Heaven forfend!
i would hate to see how bad it gets when you have people with Down Syndrome download the open source client and then calling blizzard saying "I download the source but i can't get wow to run, what? what do you mean i have to compile it. whats that? why doesnt this work right now, blizzard help plz!!"
Helpdesk: "Dude, you're only a level 0 hacker, if you try and use the open source client before you're at LEAST level 7 and have the Visual Studio skill it's gonna aggro your compiler. You don't want to do that, it's not pretty."
They don't want what happened to UNIX happen to Linux?
"But, Doctor Evil, that already happened."
The horses have escaped and had children.
In this message in 1983 a troll who used the pseudonym "Elizabeth Bimmler" started the first major trolling campaign on Usenet, attacking the group net.suicide (a support group for depression). The same group created a semi-automated trolling program under the name Mark V. Shaney. There has been a lot of mythology built up about these campaigns, probably because the person primarily responsible is a well known and respected member of the UNIX establishment, but really they're no different in nature from what the /b/tards do today.
My Macbook Pro has horrible thermal problems, and I'm using a third party program to take over my fan control to keep it cool... and mine's got an ATI GPU.
If Blizzard is selling a user interface (the client) then they shouldn't care who's improving the user interface.
If Blizzard is selling a service, then they shouldn't be implementing the security in the client: you can't stop anyone breaking in to their own computer.
What costs more, the service or the client?
Open source the part that you're not making money from, and quit worrying about Glider.
Y'all think I'm kidding? Y'all think this is flamebait?
I'm not. It's not. I'm serious. You can't stop people breaking in to their own computers. If you want to implement the security at the client, make the game run on a console.
I have a huge reliance on my PDA, which has had a huge effect on handling my organizational issues. So should I go back to being as disorganized as I used to be, instead of being the guy who does the organization? I'm just as dependent on my PDA as Steve Mann was on his Wearcam. If you use a cellphone or an addess book or a paper organizer, well, you have the same problem. This isn't a new problem, it's not a high tech problem, I'm sure Himuralabima of Babylon would have found himself just as lost without his clay tablets and stylus as I would without my PDA and stylus... heck, my PDA is almost exactly the same size and shape as his clay tablets.
In Charlie Stross's Accelerando, in Chapter 3, Manfred Manx loses his wearable and the result is, well, not good for a while. But all ends well...
Refusing to use a tool because you'll become dependent on it is only a problem if you plan on stopping using it. Steve Mann decided he was engaged in an experiment. For some of us, electronic memory aids from PDAs and Google on up are a lifestyle, not an experiment.
Is it embarrassing enough to make Ron Paul look good yet?
The Second Life building tools are actually pretty good, for putting together objects that are going to be reproduced at 3d printing resolution.
And you can extract a mesh from Second Life (and other games, but don't let Blizzard catch you :-> ) using GPU hooks and programs like OGLE.
They really need to just open source the Warcraft client. If the user interface is reducing the fun of the game by forcing people to repeat pointless activities, let the open source community fix the interface... and implement security at the server.
That would be an issue for lookupd...
Personally, I'm pretty down on the whole idea of caching resolvers like lookupd, nscd, and Microsoft DNS Client.
Security Update 2008-005
* Open Scripting Architecture (ARDAgent etc...)
* BIND
* CarbonCore
* CoreGraphics (2)
* Data Detectors Engine
* Disk Utility
* OpenLDAP
* OpenSSL
* PHP
* QuickLook
* rsync
Yeh, but I inadvertently gave it an accent. Should have been ::00fe:436a:9cf9. :)
I stuck out my contract with Sprint because I was bloody well determined NOT to pay their damn termination fee. Pity this decision hadn't happened a year or so sooner.
Heh, I was actually referring to Usenet II.
Damn, that's two Transparent Society stories so far today.
I can't wait for cheap Internet goggles, so I never have to go offline...