Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security

DNS Rebinding Attacks, Multi-Pin Variant 84

Morty writes "DNS rebinding attacks can be used by hostile websites to get browsers to attack behind firewalls, or to attack third parties. Browsers use "pinning" to prevent this, but a paper describes so-called multi-pin vulnerabilities that bypass the existing protections. Note that, from a DNS perspective, this is a "feature" rather than an implementation bug, although it's possible that DNS servers could be modified to prevent external sources from being able to point at internal resources."
This discussion has been archived. No new comments can be posted.

DNS Rebinding Attacks, Multi-Pin Variant

Comments Filter:
  • by bugnuts ( 94678 ) on Monday August 06, 2007 @07:28PM (#20136201) Journal

    We are now checking your browser for DNS rebinding vulnerabilities.
    Not without Javascript you aren't!

    But it's true, most people loooove that javascript. I can't stand it, myself, and only enable it when I absolutely have to.
  • Flashback (Score:5, Insightful)

    by Spazmania ( 174582 ) on Monday August 06, 2007 @08:33PM (#20136747) Homepage
    If you haven't read the article, I'll summarize it for you: its another critical vulnerability in java/javascript. The sandboxed script in the web browser alternately makes GET and POST requests the "same" server with each POST containing the contents of the prior GET... Only the IP address associated with the server's hostname keeps alternating between a server inside your firewall and the attacker's real server outside it. Oops.

    At times like these, I tell a story about 1988 when I wrote a BBS terminal emulator for the Commodore 64 which cleverly allowed the BBS to send and run new code on the caller's machine. Another gentleman who didn't much like me noticed the feature and arranged for a number of BBS systems to execute the code at location 64738: system reset.

    There is no safe way to run complex sandboxed code on a user's PC and no safe way to allow sandboxed code access to the network. Either you trust the source of the program and let it do what it needs to do, or you don't trust it and don't allow it to run on your PC at all. How many of these vulnerabilities are we going to run through before we finally figure that out?
  • by Sigma 7 ( 266129 ) on Monday August 06, 2007 @09:47PM (#20137325)

    You should probably consider upgrading from a 486.
    Won't protect against the buggy Javascript in question.

    As an example, let's assume that one of those shaky "Your the 999,999th visitor" ads pins the CPU at 100%. Unless you only one web browser window/tab open (if you read /., probably not), it will be running more than once and thus cause problems. Even one 100% CPU process or thread can lock down the system - especially if it's called "Spoolsv.exe".

    Dual core systems could help... but it won't be long before an SMP process can do the 100% pinning as well.

    P.S. If you hear whooshing, you probably want to wear eye/head protection.
  • by DrSkwid ( 118965 ) on Tuesday August 07, 2007 @07:12AM (#20140081) Journal
    1) run your own nameserver
    2) use a new subdomain for every request
    3) ???
    4) profit

1 + 1 = 3, for large values of 1.

Working...