Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comments

top

Are the World's Religions Ready For ET?

ray-auch Re:Paging Arthur C. Clarke... (491 comments)

Nothing was stopping the angels either, per Genesis 6-4 "when the sons of God came in unto the daughters of men" and begat the Nephilim (or were the Nephilim depending on your translation). Enoch appears to make clear they are angels, but Enoch is apocryphal so you may or may not believe it enlightens the story in Genesis. It matters not though, because the story _is_ in Genesis which is canon, and whether the "sons of gods" (or Enoch's Watchers) are angels or aliens, they are clearly not-men but are capable of interbreeding with "daughters-of-men" and producing a race of giants (Nephilim).

As regards opening up a whole new mess, all of this is post-Eden and pre-flood, man can always complain to God: "you said I had dominion over everything so what are these more powerful beings doing taking all the good looking girls" , and God will say "yeah and ? Can I remind you that was back in Eden when I also told you not to eat the ****ing apples ?".

11 hours ago
top

Bash To Require Further Patching, As More Shellshock Holes Found

ray-auch Re:highly damaging to linux on the server (326 comments)

At least with Linux, if a security hole is found (and made public or released to experts in the security community or to the relavent developers or whatever), the number of people who are able to investigate and fix the hole (and make official or unofficial fixes available) is (in most cases) significantly larger than the number of people who would e able to deal with issues in Microsoft code. And the Linux guys can have patches out much faster (and they can get into distros fairly fast too)

There is a flip side to that, which is that too many cooks with no common management may royally spoil the broth, which is what has happened.

When found, this was embargoed and should have been fixed under embargo, properly. Instead, someone pushed out half-baked patches that were proved to be still vulnerable within hours (if not minutes), and by then everything was public. So now we have everyone and his dog patching in panic mode, three, four or more(?) sets of patches now, with each one still proving vulnerable, because collectively we blew our chance to fix it (and test it) properly the first time.

The eventual fix will have to be to stop playing who-finds-the-parser-bugs-first and accept that the whole feature is a security hole and needs to be removed or radically changed - something that could and should have been predicted at the start. There are various patches flying around now that do just that, probably in different incompatible ways. Those changes will, inevitably, break some stuff - and of course we could have looked and tried to figure out the extent of that, and mitigated the effect and been ready with the announcement, if it were still under embargo, but we blew that chance.

I am all for saying that the open source development model is better - but this really is not the best example to use to illustrate it, in fact it's already heading into embarrassing farce territory.

2 days ago
top

Bash To Require Further Patching, As More Shellshock Holes Found

ray-auch Re:Remote Exploits (326 comments)

I can't imagine the stupidity of these security folks or programmers. bash is not remotely, remotely exploitable. Hint, there a program that listened to a network connection, then, it decided to try and pawn off security and trustworthiness to another program. That trust was misplaces and that program is wrong.

If you accept bash commands on a network connection and feed them to bash, then you are an idiot, full stop. Now, if you validate the arguments, the format and the content of the command, for example, you allow two formats true, false. Then, reasonably you can call bash to run those two commends. What you can't do is accept any arbitrary string and pass it to bash.

Problem is that in unix the way is for tools to call other tools, and the shell is so pervasive it could be anywhere. How do you actually _know_ if you are calling bash ?

* If you run /bin/sh are you calling bash ? Should you always check first ? Can you even check ?
* same for calling system() etc.
* If you run any other executable should you always check whether it is a script first ? Can you even check always ?

And this applies all the way down the pipeline, parts of which may be user/admin configurable.

Accept what you prove is trustworthy. Be willing to fix it, and claim responsibility when you are wrong.

No meta characters in environment variables, trivial, not meta characters in arguments, trivial. The argument should be a number, 0 to 255, check it _first_, then pass it.

Where in the pipeline ? What if you don't _know_ what the data is supposed to be at this point (only some other tool might do, down the pipeline, how then do you prove it is ok ? What does "no meta characters" mean in the context of an HTTP Cookie, or an email subject line ? - it is meaningless, arbitrary text is valid data in either case.

I thought we learned this with all the sql commands from the network bugs. We seemed to do the right thing for them, why do they have it so wrong this time around?

What we learnt was to properly sanitize and/or quote text that was executed as SQL commands. At the point that we knew it was going into a SQL command. Your web server doesn't know what you are going to use each form field for, "Robert'); DROP TABLE Students" is perfectly valid as a subject for a forum post, but as a user name in a SQL command it needs quoting first. The web server can't quote it, the cgi script or whatever down the line needs to quote it - if and when it gets used in SQL. Now, the web server also does not know and should not need to know what language a cgi script is in, but if it is bash, then bash will execute data as code before the script has chance to verify it.

This generalises to the whole pipeline - any caller may not know what the data it is passing down the pipeline in the environment (or otherwise) actually _means_, or what is valid/non-valid/malicious. Such determination can only be made by the callee that understands the data - but bash may execute it before it gets there.

Let's assume you are right and we can compare with SQL Injection. With SQL Injection we learned we had to properly quote data before feeding it into SQL, and fix all the places we do that. So, with bash injection, now that we know about it, to do the same we would need to sanitize / quote all environment variables whenever we call bash. Except we don't know when that is (see above), so you really mean that every program that execs any other program or feeds into any other program in a pipeline where that program might possibly be a shell script, needs to quote environment variables. That is just about every unix program ever written (and, er, where/when are you going to unquote that data ?).

Or we fix bash, the program that is actually blindly executing data as code.

2 days ago
top

Bash To Require Further Patching, As More Shellshock Holes Found

ray-auch Re:Internet of Things (326 comments)

maybe, "How many hackers does it take to change a light bulb ?"

2 days ago
top

Bash To Require Further Patching, As More Shellshock Holes Found

ray-auch Re:Still waiting... (326 comments)

Would be better if you stopped waiting and started checking.

10secs on google finds lists of shellshock attack vectors including:

qmail, procmail, exim, some inetds, ssh, openvpn, dhclient

That is just some of the ones the good guys have found and advertised so far...

2 days ago
top

Ask Slashdot: Software Issue Tracking Transparency - Good Or Bad?

ray-auch Re:Not so public disclosure (158 comments)

Worth listening to sales, sometimes there is value in what they say, and you need them on side - it isn't fun (or good for job security) writing great software that they can't or won't sell. The suggestion is good as far as it goes but I would say it isn't as simple as that.

Unless you are open source, your dev teams bug trackers should be their area and confidential to them, they may not all be commercially aware customer facing people, they may speak their mind in choice terms about some bug reports, and you shouldn't have to be constantly afraid of that turning up in front of the customer. It isn't just dirty laundry, it's the whole cleaning process and every dirty comment you make whilst doing it.

Then, each customer has their own issues which should be confidential to that customer (and you). Some issues may not be bugs but embarrassing customer mistakes, and customers _will_ (sooner or later) put information into an issue that is commercially confidential, personal information (data protection) or security related. Sometimes this is necessary - bugs may only be tripped by certain data, and it isn't the customers job to determine the general case, it's your job when investigating. Support and dev need to understand that issues are private to a customer, but also sales so they can explain it positively to prospects: "can we look at your issue list ?" "we can't show you customer reported issues because we treat them as confidential to that customer - we believe customers should be able to report exactly what happens which may include their data, rsther than be required to create a general test case". Customer issue lists are not a concern of sales but rather account management - the customer account manager may be in sales, but if so it is a different role they are doing.

Then you (maybe) have general issue list(s) that are visible to all customers - effectively a dynamic tracking view of what will be in the release notes (see below). You need to re-create issues here from the customer reports - not just blindly copy customer report - and really these should be general cases not just what the customer reports. E.g. customer reports issue with Web UI display of account named "P&O", you establish it's an issue with ampersand, and what you report to all customers is that there is an issue with ampersand, otherwise you risk reporting too narrow a bug and exposing customer confidential information. Not every issue will make it to this list, only if it is of general concern, and issue that affects a configuration only used by two customers who have already been informed has no relevance here. I still see little value in this list being public beyond customers, but it should be expected that it might become public at some point (possibly via a customer) and information in it should be written accordingly, at very least it is available to all customers. For these reasons sales may sometimes be involved in decisions as to what goes on this list.

For betas and dev builds etc., maintain separate lists and give access only to those customers who are running those versions, make them feel special, but also your SLAs etc. will be different for non-production versions and this helps keep that clear.

Finally, release notes - fixed issues and known outstanding issues. If you provide public downloadable demos, or you provide demo installs to sales prospects, then these need to come with release notes, so these documents go (at least) beyond your customers. For that reason you don't just dump (any of) the lists above into the release notes, each issue needs to be vetted for inclusion (see above for relevance, plus you want to inform not overwhelm) and rewritten to show your customer service in a positive light - this is effectively part of your shop window.

I would recommend trying to get sales (and maybe marketing) involved in reviewing (and editing) release notes, they are technical documents that need to be customer relevant and readable, sensitive to commercial needs and priorities, and hence need some sales/marketing input.

Yes, really, honestly, and my reasons are:

[stated reason]: This needs your (sales) input because we've written it as a technical document and we may not be aware of all the commercial priorities and sensitivities and may not have used the best customer-facing language, you guys are better than us at this
[real reason]: I want to make sure you sales guys have read the ****ing release notes and aren't out there demoing year-old versions and apologising for bugs we fixed months ago

If they don't want to engage with this, then a) you tried and b) they can't complain about it later...

2 days ago
top

First Shellshock Botnet Attacking Akamai, US DoD Networks

ray-auch Re:Here's what I'm noticing on a web server (236 comments)

Check your distro. Believe RedHat at least have newer allegedly more complete patches - although there are also posts saying you'll need a support contract for some older versions of RedHat.

My guess is that initially this was embargoed while GNU/FSF guys "fixed" it, but when we find out fact that the fix was no good everything is already public so now everyone downstream is trying to fix it themselves as fast as possible - RedHat etc. may do their own without waiting for upstream. It's now that you find out how good your support is, from whoever you paid for it or from the guys who work for free if you paid no one.

If you want the diy approach, personally I would look at the initial patch for where the offending code is and rip out the entire "feature", I suspect very few scripts will break.

Alternatively, patch bash using rm.

5 days ago
top

First Shellshock Botnet Attacking Akamai, US DoD Networks

ray-auch Re:Heartbleed comparison might be a bit overblown (236 comments)

I think the bigger than heartbleed comments might be a bit overblown. If you're running CGI and your web server is running as root, you probably have a serious problem. Otherwise, it's just a PITA when you have other things to work on. Can anyone tell me why the script kiddies are scanning 23? I haven't seen an open telnet port in years. From all the reports I've read, about the only things vulnerable are web servers running CGI which was pretty vulnerable before.

ssh is also vulnerable (often configured to pass TERM and maybe LC_*)
Git repos using locked-down ssh - vulnerable
dhclient - vulnerable
CUPS - vulnerable

Those are just the ones we know so far.

It is different to heartbleed, and it could indeed get bigger. Heartbleed required zero effort to get the data but then needed some luck and some work to find keys or login info within it. Manual work required before you could break into a system.

ShellShocked on the other hand is direct, trivial, remote code execution. Attacks can easily be fully automated - it is wormable, trivially. The question now is not whether or not fully automated worm attacks will happen or when - they already are - it is how many servers they will get.

And that is all before we start looking at all the embedded Linux out there that may have bash, and often have cgi. It may take longer to find exploit vectors for those, but it will also take longer to patch, and some may not be patchable. Add in to the mix that small business / home routers often also run dhcp servers, and that dhclient is vulnerable, and a router compromise can open up any unpatched client machines inside the firewall.

No one knows how big this _will_ get, but it _could_ be bigger then HeartBleed, easily.

5 days ago
top

First Shellshock Botnet Attacking Akamai, US DoD Networks

ray-auch Re:Here's what I'm noticing on a web server (236 comments)

So... unless your CGI script is extracting a header field and feeding it to a bash script... you should be okay in terms of HTTP requests with this in their header?

Keep your head in the sand, it's less scary that way.

Or realise that your CGI server feeds headers to your CGI processes in environment variables, because that is how CGI is supposed to work, and that it isn't just your CGI script it is every single process it starts (all children and descendants) that must not be a shell script and must not use system() etc. Perhaps then also note that CGI is just one vector that happens to be being attacked right now and there will be others, some we probably don't know about yet.

Or you could assume you are vulnerable and patch bash, or remove it.

Your web server might be responding with a 200 response code, but that's just because whatever the URL requested is, is being successfully sent.

Thoughts?

Correct - no need for attacks to cause any error at all. May be possible using an http header you aren't logging at all, giving you no way to detect it.

However, this has nothing to do with users on your box maybe trying to do privilege escalation with this bash trick. But... this isn't a privilege escalation trick - the user shouldn't have any more access to the system than he would have with running the commands directly, right?

Find a setuid script or setuid program that somewhere uses the shell and it's a privilege escalation too. Such things _should_ be very rare by now, but not impossible that some still exist.

5 days ago
top

First Shellshock Botnet Attacking Akamai, US DoD Networks

ray-auch Re:Amazing... (236 comments)

1. the first fixes, within 24 hours of announcement, didn't actually fix it fully - in fact I suspect it will still be exploitable in some way or other until the "feature" of treating environment variables as code is removed completely
2. providing an incomplete fix may be worse than taking a bit longer to properly QA the fix - a lot of admins may believe they have patched this based on the first announced vulnerability tests and the first set of patches, but in fact they are still vulnerable with a trivial change in the malicious bash code
3. it was less than 24 hours after first being made public - this may be entirely unrelated to when it was first found

We have no idea who found it first or for how long it may have been used covertly (did NSA etc. know of heartbleed before public knowledge ?)
We don't know what prompted someone to be looking for problems in code that hasn't changed for 20+ yrs.
It is so trivial to get remote code run with this bug (no unexpected new process or login or errors) that I doubt it will trip any intrusion detection systems.
If you can use an http header that isn't logged, then you could run code on the server and extract information and it may be completely undetectable.

Something else we don't know is how the FBI really got the Silk Road server to cough its real IP address. The FBI claim they put "miscellaneous characters" into the login form and it just happened to send the address back. You can believe that if you want. It may or may not be related (I have no idea about the silk road server setup), but a handful of days after the FBI put their story out someone is looking for security holes / bugs in very old bash code. Maybe there was no trigger and they just happened to get bored one day and decide that looking for bugs in bash would be fun. Or maybe there is more behind this than we know.

5 days ago
top

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

ray-auch Re:Preempting dumb discussion (317 comments)

Perhaps we should just be completely accurate and say: Linux is not vulnerable. GNU/Linux _is_ vulnerable. At least we keep RMS happy :-)

about a week ago
top

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

ray-auch Re:USER-AGENT (317 comments)

And SSH if any environment variables are passed (e.g. TERM)
And Git servers using restricted ssh
And CUPS
And probably other services that just haven't been found yet

about a week ago
top

Remote Exploit Vulnerability Found In Bash

ray-auch Re:Remote? Vulnerability? (399 comments)

dhclient and dhclient-script

and yes, the target machines in that case would be laptops and mobile devices.

For servers, I have read elsewhere that cPanel at least is vulnerable. Not many servers using that, right ?

about a week ago
top

Why India's Mars Probe Was So Cheap

ray-auch Re:Risk management? (200 comments)

> Faster, Cheaper, Better.
> Pick any two....

F35.
Your argument is invalid.

Cheaper than an F22, faster than a Cessna.

about a week ago
top

Remote Exploit Vulnerability Found In Bash

ray-auch Re:Remote? Vulnerability? (399 comments)

Two words - dhcp client. Think how it works on Linux.

about a week ago
top

Ask Slashdot: Finding a Job After Completing Computer Science Ph.D?

ray-auch Re: Read Slashdot (471 comments)

"Hide the PhD." How do you then explain the 6 year gap in your resume?

"Misc. contract work"

Interesting, how many contracts, for whom for how long, and can you provide a reference from one of those ?
Why did you quit contracting to go back to perm ?

Hint: Do NOT lie on CV / resume - at some point it _will_ come round and bite you in the arse. If not at interview then later, when it turns out you effectively lied to get the job, and hence can be immediately fired for it (even if they don't, you think that is helpful in your annual salary review ?).

about a week ago
top

Ask Slashdot: Who Should Pay Costs To Attend Conferences?

ray-auch Re:Summary of the summary (182 comments)

Get a new personal life, clearly.

about two weeks ago
top

Ask Slashdot: Alternate Software For Use On Smartboards?

ray-auch Re:Regular boards are a lot smarter (96 comments)

Smart boards can be useful for businesses. The people who manage schools want the schools to have the same stuff as the businesses, so they end up investing in smart boards. Unfortunately, they are not all that useful in school.

It's funny, I've never, ever (in 20+yrs in IT including plenty of travel to client-sites) seen a smartboard used in business and only once seen one (possibly broken, never used) in a business at all. On the other hand I have seen loads and loads of them in schools.

In business it's always a flip chart and/or whiteboard, if you're lucky some pens that work, plus a projector - probably vga and lo-res only, but generally you think you are lucky if it actually works, projector screens are optional, frequently just a bit of wall, white if you are lucky. Only schools seem to have the $$$$ smartboards.

about two weeks ago
top

Proposed Law Would Limit US Search Warrants For Data Stored Abroad

ray-auch Re:Why purchase service from provider in US then? (131 comments)

If it is a fallacy then it is a very successful and convincing one, because an awful lot of EU business is based on it - business with customers who have to ensure their data storage and hosting complies with EU data protection laws. That the data remained in the EU and subject to EU law was a _big_ selling point. MS doesn't realoly have a lot of choice but to stand behind this "fallacy", because if it falls it threatens their entire EU hosting (cloud) business which is what they built the Irish data centre for.

about two weeks ago

Submissions

ray-auch hasn't submitted any stories.

Journals

ray-auch has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?