Forgot your password?
typodupeerror

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

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) 320

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).

Debatable.

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: Please identify submitter honestly (Score 2) 221

by plcurechax (#47976635) Attached to: Outlining Thin Linux

This submission was made by snydeq who may or may not be Paul Venezia, but certainly appears to have a clear vested interest in frequently promoting Paul Venezia's column and other articles from Info World on a nearly weekly basis.

Considering the overwhelmingly poor quality of the vast majority of Info World's trade rag (slang trade magazine), where most of the better "articles" (i.e. aka "filler," the stuff between the ads) tend to be cribbed from vendor's white papers, don't seem to merit being frequently promoted at Slashdot unless there is a financial arrangement in place, in which case the ethics of journalism would indicate that such a financial arrangement should be disclosed to readers.

Not that I'm suggesting Slashdot considers itself involved in journalism, regardless of the usage of the terms such as: articles, submissions, and editors in the Slashdot vernacular. I will mention that the US FTC publishes March 2013 disclosure guidelines for sponsorship, marketing, and promotions.

Comment: Re:Why did he lose tenure? (Score 1) 167

by plcurechax (#47974657) Attached to: Anonymous Peer-review Comments May Spark Legal Battle

There's a third, more mundane possibility: he lost his tenure because he quit. When he lost his new job offer, he went back to Wayne State asking for his old job back, and they said no.

Well in fact he did get his old job or position back at Wayne State, Michigan, but at the reduced level of pay, and without the other benefits of tenure. This was most likely simply the administration trying to control their expenses, as they had most likely planned on replacing him with a non-tenured professor.

> Moral: never, ever, quit your current job until the ink is dry on the legal papers for your new one.

Good intent, but often hard to keep in practice while also managing obligations such as the notice period for resignation (14-90 days), and planning (i.e. relocation) - most employers won't continue to pay you while you move away from your place of employment. In terms of selling a house, moving out of state / province, these things are fairly significant events that take time and away from your current job.

I don't know the legally binding nature of a job offer, I suspect it varies by state/ province and by the actual offer, but they do not offer the same protection as a contract of employment, a document that I have normally not been able to sign until the first day of work.

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?

Encourage.

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.

The Force is what holds everything together. It has its dark side, and it has its light side. It's sort of like cosmic duct tape.

Working...