Slashdot Mirror

Bzzt, wrong. MP3s have been the vectors for exploits too.

>Your MP3s are safe from viruses

http://www.exploit-db.com/exploits/14309/
http://www.gnucitizen.org/blog/backdooring-mp3-files/
http://www.theregister.co.uk/2002/04/29/winamps_malicious_mp3_vuln/

Any interpreter can be used to run an exploit if the interpreter has a flaw. The seemingly huge number of flaws in interpreters shows that it is either hard or people that write software make a lot of mistakes.

PDF reader... sandbox...

A Document Format that needs a sandbox. I don't have a sandbox around my text editor, nor my PNG viewer, nor my MP3 player... Tell me again, why do we need our document formats to be little programming languages?

Image formats or even MP3 you mentioned can be a viable transport for malicious code too. If you think it over well enough, even text files can be used to exploit e.g. your text editor's buff overflow vulnerabilities...

Until someone works out the algorithm, then pre generates all the possible passwords. Then you just have to worry about every single device out there.

I mean, not like that has happened before, perhaps even more than once.

Granted though, better than the current setup of same default password everywhere, but still, not that much better. You might as well pregen a random password and stick it on the device. At least then you need to physically be there to find out what it is.

The UPnP standard lacks any authentication mechanism. Turning it on means anything in your network can open any ports to anywhere it wants. According to this site https://www.kb.cert.org/vuls/id/347812 and here http://www.gnucitizen.org/blog/flash-upnp-attack-faq/ there is even a flash exploit that can be used with uPnP to reconfigure your router. UPnP was dead on arrival. Any router vendor that doesn't ship with it off by default is a retard.

With suitably malicious design, it could be a very convenient tool for surveillance(a visited link scanner seeded with a list of URLs that the feds might be interested in your having visited, would be a trivial example, various sorts of cookie snooping, cross-site scripting, history inference, and so forth attacks could also be used, in addition to boring old IP geolocation and date/timestamping).

However, in absence of these sorts of fairly overt malicious features(which would fly right past the noobs; but would be hard to hide from security researchers for more than a few minutes), I'm not sure that a move from a paper 'n civil servants based frontend to a web based frontend actually makes all that much difference. In both cases, you are doing some nontrivial data dump/exchange with the state, either because some law obliges you to, or because you want the state to do something for you based on that information. That act of data transfer is the point of the exercise, and occurs in either case. Also, unless the British civil service is far behind the times, the data end up being dumped in a big database somewhere no matter which frontend you use. It isn't as though a people and paper frontend implies a people and paper backend, just a more expensive translation process.

With the exception of fairly visible malicious techniques, a web site doesn't provide all that much useful information in itself. Any attempt by the state to use such techniques should, of course, by resisted fiercely by both technological and political means; but fretting about cookies is largely a distraction from the serious area of data disclosure, which is whatever forms you are going to the website explicitly to fill out.

I found this pretty interesting: "Authentication [across the Web] would be really nice," says Tunkelang. "The anonymity of the Internet, as valuable as it is, is also the source of many of these ills." Having to register an e-mail before you can comment on a blog is a step in this direction, he says, as is Twitter's recent addition of a "verified" label next to profiles it has authenticated."

The idea of universal authentication has been tossed around for a while. I feel like the biggest drawback is privacy (we'd have to trust some universal authentication system to hold onto some identifier even if posting anonymously) and the biggest obstacle is the need for universal participation. It's kind of too late to make an opt-in system. But I've liked the idea ever since early sci-fi interwebs (read: Ender's Game) had SOME kind of authentication.

Let's not forget upnp, which a ton of fools leave enabled:

http://www.gnucitizen.org/blog/flash-upnp-attack-faq
http://www.gnucitizen.org/blog/hacking-with-upnp-universal-plug-and-play

Ask 20 random people outside of a computing environment how they disable javascript in their browser and gauge their responses, now ask about Iframes. A growing number of javascript attacts are targeting arp in interesting ways, upnp or no. If you're not in a static arp environment, do the research *now*.

I simply won't use NoScript since the recent negative news about it. I won't use Firefox, either. Opera offers a much wider and simpler blocking ability of content across the board. It's proprietary, but so is the flash plugin which most of you swallow while using Firefox. So are the graphics drivers in a lot of your *nix setups.

Let's not forget upnp, which a ton of fools leave enabled:

http://www.gnucitizen.org/blog/flash-upnp-attack-faq
http://www.gnucitizen.org/blog/hacking-with-upnp-universal-plug-and-play

Ask 20 random people outside of a computing environment how they disable javascript in their browser and gauge their responses, now ask about Iframes. A growing number of javascript attacts are targeting arp in interesting ways, upnp or no. If you're not in a static arp environment, do the research *now*.

I simply won't use NoScript since the recent negative news about it. I won't use Firefox, either. Opera offers a much wider and simpler blocking ability of content across the board. It's proprietary, but so is the flash plugin which most of you swallow while using Firefox. So are the graphics drivers in a lot of your *nix setups.

...in fact, I would *expect* Google to do this before implementing OpenID. The fact is, OpenID has some security issues:

http://www.gnucitizen.org/blog/hijacking-openid-enabled-accounts/
http://drupal.org/node/280592
http://seclists.org/fulldisclosure/2008/Aug/0123.html

What do you know, the last one was submitted by Google's own Ben Laurie of Google's Applied Security team. They have obviously been assessing the security of this product and we can conclude what the results were. There is no way Google will implement vulnerable code, if OpenID 1/2 is insecure (it is) and needs to be redesigned in order to become secure then so be it. The real problem IMO is that Microsoft *did* implement a system that is flawed.

When Google releases their (hopefully) secure version, I predict everyone will move to that and like it.

Plus 14 bits of port number (i.e. where in the 48k-64k range it is)

Oops, yes. My bad. Sequentially incrementing port numbers != predictable starting port. To be fair it was early and I was hung over ;-)

and 32 bits of IP address. Really.

Think about it: if you have to guess at the transaction ID, that means that you are in a position where you can't see the stub resolver's queries, so you are also not seeing what IP those queries are being sent to or what source ports have been used.

The IP address might be guessable. If you're going to the effort of targeting stub resolvers in the first place, it might not be too much extra effort to whois the IP address and guess the names of the ISP's caching resolvers. (The only situation I can really see this sort of effort being worthwhile is where, say, a particular ISP habitually supplies a particular gateway device, which turns out to have NAT/firewall flaws allowing packet injection into the local network.)

With a recursive resolver using a single port, an attacker can discover and deduce everything but the transaction ID without doing anything but getting the target to resolve some names, while that is simply not the case with a stub resolver.

I'm still not convinced it's impossible, but I'm pretty sure it wouldn't be worth making the effort. There are almost certainly bigger issues.

Regarding DNS design: short of net-wide DNSSEC rollout (ha! We'll see IPv6 transition first..), a medium-term approach might be to start with the assumption that we can't be 100% sure that any individual answer is genuine, but that we can be pretty sure that a sequence of successful spoofing attempts is extremely unlikely. How do we re-engineer caching resolver behaviour (caches are the key target, because of the cascade effect of a successful poisoning on end users) to minimize the amount of trust we place in a single reply packet?

Paul Vixie made some suggestions back in '95 (see 7.2: "What We Would Like To Fix .. Hierarchical Cache.") It might make sense to return additional RRs to the calling stub without caching them, but then setting up another request to grab those names, in order to prime the cache and so minimize network traffic, but at the same time not delaying the first requester's query by too long and only risking returning false information to one client.

I'll admit my grasp on this is a little fuzzy around the edges, I haven't had much experience with DNS guts in the past (I'm hoping Dan Kaminsky's explanation will include some analysis which might clear the waters for me.) The issue as far as I can see it is that the additional RRs, which were originally only needed to solve one specific problem (glue for zone delegation), have been used as a general mechanism to prime caches (e.g. when doing MX record lookups), and so nobody wants to tighten up the processing behaviour of the caching resolvers.

I don't know whether this sort of effort is worth it, a jump to DNSSEC might actually be simpler, and the source port randomization is a good fix for the moment. Network speeds will continue to get faster, however, and I'm sure some people will continue to put nameservers behind NATs that eliminate source port randomness. Also, flaws will presumably continue to be found in random number generators. A bit of further thought might be wise before the next issue crops up..

It's a little scary when that "odd app" includes visiting a webpage with a malicious flash script.

http://www.gnucitizen.org/blog/flash-upnp-attack-faq/
http://blogs.techrepublic.com.com/tech-news/?p=1902

Not necessarily..
It is also possible to change settings on a router using UPnP using a malicious flash script...
See http://www.gnucitizen.org/blog/flash-upnp-attack-faq for details.
Most home routers have UPnP turned on, so you're not safe just because you have a good password.
I would assume that most 3com gear does not have UPnP, so it is quite likely that you specifically are safe.
Of course, anyone with a security clue has been saying UPnP is a BAD idea for a long time, but it used to be client side malware people were worried about, not well formed flash on any webpage...

1) TURN OFF UPnP! Anyone who has been listening to Security Now has known about this issue for the past two years. UPnP is by design insecure. If it is turned off it can't be used to attack your router. The only reason to have it is so that you don't have to configure anything when a program decides it needs to be open to anyone contacting it. Personally, I would rather have control over when someone else can talk to my computer.

2) Browse with No-Script (or similar settings in the other browsers). If JavaScript and Flash are blocked as you are browsing sites and only turned on when you need them, you can't be hit by drive by attacks like this one. Heck, I've seen maybe 2-3 banners in the past couple months with a combination of No-script, Adblock, and Flashblock.

3) Change the default settings of your router. This won't prevent the attack described necessarily, at least without the above steps, but it will make sure those steps aren't for nothing. The most important thing this prevents is a CSRF attack to turn UPnP back on, even if you have it off. This also would require not staying logged into your router when you don't need to be (and routers without gaping CSRF holes built in that don't need passwords)

I agree - the problem is in the underlying Flash plugin, and uses the documented functionality of the 'navigateToURL' function and the 'URLRequest' object. This isn't as much a problem with browsers or Flash, though, as much as it is a weakness in UPnP.

Whatever browser you use, if you have one of those home Internet Gateway routers, then make sure UPnP is disabled and you're not using the default password!

Also, keep an eye on your other networked devices (phones, cameras, etc.) - they may also support UPnP and would be vulnerable.

Here's an update from GNUCITIZENS with further clarifications: http://www.gnucitizen.org/blog/flash-upnp-attack-faq

"httponly" is very interesting - didn't know about that. how often do you want to play with your session cookie in script? i've definitely never needed to!

tho this isn't actually about cookies, from the actual article - it's google allowing a form submitted from an 'evil' website to set-up a 'forwarding rule'. they call it a "Cross-site request forgery".

Some interesting points

• nothing to do with cookies - it is google not correctly validating a form submitted from an 'evil' website
• nothing to do with XSS - the ARTICLE calls it "Cross-site request forgery".

It has nothing to do with it being specific in the MySpace soley, it can be used anywhere.

My source for it was: http://www.gnucitizen.org./

It does not have your history... but it could if it tried a brute-force attack. Neat trick, btw :-D.

The javascript is at http://www.gnucitizen.org/projects/attackapi/build /lib/AttackAPI/HistoryDumper.js and it works by making an 'a' tag, then checking if it was visited or not. So it is able to see if a link has been visited before, but it can't dump your history in a normal fashion. I bet it probably isn't exactly a feature... but hardly something to be paranoid about.

Here's a -1 day exploit that works in Firefox 2.0. Visit say, www.nba.com and then go here: http://www.gnucitizen.org/projects/attackapi/build /demos/HistoryDumper.htm - it has your history. Thank goodness Konqueror is safe.

With respect to the RSS issue, I assume that the author of the article was trying to explain in a very poorly-worded way discoveries like these:

http://www.spidynamics.com/assets/documents/Hackin gFeeds.pdf (warning: pdf)
http://www.gnucitizen.org/blog/cross-context-scrip ting-with-sage/

etc, etc.

However, I agree that most of the points were simply various different ways unchecked user input can be exploited, and the banking example was absolutely horrible.

My overall impression was that the author either had no idea what he/she was talking about or was aiming for a much less computer-literate audience than slashdot.