Forgot your password?

Comment: Re:Call it what you will (Score 1) 319

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

The wrong mechanism (a semi-persistent environment) is being used to transfer what should have transient data. That is a vulnerability in the spec.

Hm. Okay, I'll buy that argument.

In practice, if the CGI developer follows best security practices it shouldn't be a more significant problem than any other "untrusted input" path, and whatever invokes the CGI does have the option of cleaning up the environment instead of accepting the default, but it's fair to say there's a flaw in the spec.

Comment: Re:Call it what you will (Score 3, Insightful) 319

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

The fact is that bash allows external entities to poison environment variables ahead of invocation, causing unintended behavior in bash when it is launched as a child process.

Well, it's not that it allows external entities to poison the environment, it's that it gives the finger to that basic secure programming practice where you should just assume that externally provided input is tainted data.

(you could say that there is a design vulnerability in CGI - and I would agree about that).


There's nothing in the CGI specification that requires or suggests that there needs to be any kind of intermediary in handling the reqests aside from the web server. The environment is a perfectly legitimate way of passing data, and if the web server calls the CGI safely (i.e. pipe()/fork()/exec()) there's no reason for a transient interpreter like bash to get involved. And, aside from security, the performance hit of invoking a shell just to launch another program makes it a bit silly to do it any other way.

And I'd point out that it's possible to explicitly control the environment of a subprocess (i.e. execle()), so anything calling a CGI program can at least sanitize things to minimize any damage. Not that the CGI should depend on the caller to sanitize things, of course.

On the other hand, the environment is a perfectly stupid way to pass code around.

Comment: Re:"could be worse than Heartbleed" (Score 1) 316

by c (#48001101) Attached to: Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

The only communication mechanism for talking to the subshell is the environment.

Well, the easy communication mechanism is the environment. And, quite frankly, I don't have a particular problem with bash treating stuff that bash intends to be a chunk of code as code. It's just random other bits of the environment that aren't intended for bash that are the problem.

It's *nix, though, so there's many more ways to pass data around between processes than just the environment. Even if you've gotta use the environment, why not go with a env variable namespace, like "BASH_FUNCTION_FOO=()"?

Comment: Re:"could be worse than Heartbleed" (Score 2) 316

by c (#47998843) Attached to: Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

Try to understand, this is not about executing bash scripts as cgi, and it's not about sanitizing input. Period. It is about httpd setting environment variables from unsanitized user input when calling ANY cgi.

Well... no. The root of the problem is bash treating something which really should only be considered data as code.

When I hear the words "Environment Variables", I don't think "well, some random bozo is going to look at those and just up and execute 'em". For bash to be treating the contents of the environment as anything other than dumb strings is, quite frankly, a Very, Very Bad Thing. For variables being set within a shell script, sure, they're intended for bash. But for data passed from program to program and not really even intended for interpretation by any specific script engine (which is fundamentally what environment variables are for), it's incredibly dumb.

Comment: Re:why does the CRTC need this list? (Score 1) 324

by c (#47950815) Attached to: Canadian Regulator Threatens To Impose New Netflix Regulation

Personally, I like the idea of that. It encourages and funds a lot of Canadian artists that might otherwise get swamped out of the market by monied American interests.

Personally, I would much, much, much rather the CRTC enforce rules for true network neutrality for Canadian internet users and find some other way to promote Canadian content.

Or, more accurately, for someone else to force the CRTC to go that way, because there's pretty much zero probability that they'll do it without coercion.

Comment: Re:Everyone loses (Score 2) 474

by c (#47946283) Attached to: Scotland Votes No To Independence

The problem with relying for support for separation from the younger generation...

Well, yes. It still takes at least a generation for them to work it out of their system. 40 years might do it, but seeing where we are now in Canada I think it's going to take another 20 or so before we can really feel comfortable that separation is truly dead.

The reality is that there's more people in the RoC (Rest of Canada) who would vote to kick Quebec out than there are Quebecers willing to pull the trigger on separation.

Oh, definitely. And to some degree, I think the growing understanding that Quebec wouldn't be able to unilaterally dictate the terms of a separation actually proceeded is one of the biggest factors in killing the movement.

Comment: Re:confused (Score 1) 358

by c (#47946095) Attached to: U2 and Apple Collaborate On 'Non-Piratable, Interactive Format For Music'

Apple also sells music in its lossless format, and there it's hard to get "robust" without annoying the listener.

No argument that it's hard.

But if Apple (I highly doubt U2 is directly involved in the research itself) did manage to develop a robust audio watermark that doesn't suck, it's understandable how someone would get the impression that it might result in an "unpiratable" format, at least within the bounds of the Apple walled garden.

Comment: Re:Everyone loses (Score 1) 474

by c (#47945451) Attached to: Scotland Votes No To Independence

The separatist movement here has burned itself out, the generation who were pushing for it being seen as burned-out old farts. Go back to the UK in 40 years and tell me that everyone lost.

From what I read of the demographics, it's mainly the younger generation of Scots that supported separation. They're pretty much at the stage of Quebec in the 70's.

Comment: Re:Canada & Quebec (Score 2) 474

by c (#47945397) Attached to: Scotland Votes No To Independence

I wonder if this will silence or encourage the separatists that want Quebec to leave Canada?


The margins are way too close. If it would've been more like 75% against, the Quebec separatists might have taken a bit of a morale hit, but 55% ? That's a "Please Play Again" for a separatist. The 1980 referendum was 59% against and it certainly didn't stop them.

The real question is whether the Scots are going to be smart enough to tar and feather the next bunch of politicians that decide they want to run a country? I'm not optimistic.

Comment: Re:confused (Score 1) 358

by c (#47945283) Attached to: U2 and Apple Collaborate On 'Non-Piratable, Interactive Format For Music'

Because it shows that neither know what they are talking about. If I can HEAR it, I can copy it. And the quality can get pretty damn good depending on how the sound is captured.

The only way I can see something like that working is a robust audio watermark containing the purchasers iTunes information. Won't stop copying directly, but would theoretically allow them to go after a "source" and possibly publish revocation lists that some devices could support to suppress "pirated" music.

Of course, that would only be applicable to online stores (I assume the record companies would force other stores to toe the line on the technology) and likely could only be enforced on iDevices. It obviously could be trivially defeated by ripping the music from a CD (for that short while we still have mass-pressed anonymous, physical media), pirates buying music using throwaway store accounts, or other peoples accounts being hacked.

But, let's face it, at this point the best they can hope for is deterrence rather than outright prevention.

Comment: Re:Keyboard (Score 1) 216

by c (#47932393) Attached to: iOS 8 Review

I think you're overselling it somewhat. I've tried the swype systems, and I always devolve to just tapping. Same with my friends that have access to it. Out of 4 of us, all of us hate swype based systems. That's not data, obviously, it's just an anecdote.

I think the GP is overselling it a bit too, but I've been using the standard Android keyboard for a bit now, which includes swype-like typing, and I'd have a tough time switching back to just tapping. It's substantially faster and generally as accurate as tapping and quite a bit better than any miniature hardware keyboard I've tried. I don't know that if it wasn't built if I'd have bothered downloading Swype or Swiftkey, but it's nice to have the option.

In some ways, it reminds me of the difference between Newton HWR and Palm Graffiti; you had to learn some new patterns to use Graffiti, but when you got used to it, it was light years ahead of the performance of the natural handwriting recognition of the Newton.

"More software projects have gone awry for lack of calendar time than for all other causes combined." -- Fred Brooks, Jr., _The Mythical Man Month_