I've worked on-and-off in healthcare and the standards for transmitting *anything* are ancient and bad. Formats like HL7 and ASTM are ancient delimited-text formats with no UTF-8 support, no encryption, and even have RS232 ACK/NAK packets in the standard.
RS232 didn't have packets. It had wires. It didn't have ACK/NACK either. It had CTS/RTS and DCR/DTR. There were some secondary signals (STD, SRD etc) that were rarely implemented after 1980.
I just tried and successfully passed the variable "_BASH_FUNC_thingy" with the value "my_attack" through my apache web server to a CGI script using a url entered into a browser.
No, you get something like QUERY_STRING="_BASH_FUNC_thingy=my_attack", which is harmless because function definitions inside QUERY_STRING are not being evaluated after the last update.
No I didn't. I'll play with bash versions and see if there was a change. I don't think so though.
Fortunately for the evil doers, they don't have to be bound by past vulnerabilities.
Just give it a name that the script already uses.
If the script uses functions passed through the environment variables, it is now going to be written such that those variable names are prefixed with _BASH_FUNC_ because the new changes require it. So the attacker follows suit. The point being that the attacker can indeed modify the name and he or she or it can modify it to suit the script being attacked.
The underlying problem is using environment variables (I.E. data) that get executed by the interpreter. Don't do that. You can write CGI programs that are invulnerable, but you can't be sure every CGI program in every bit is system and web bloatware is invulnerable.
Better to fix CGI. Give it a new interface. E.G. It calls the program and hands it a pointer to a file that contains the variables. Or uses any other form of IPC. Just make sure it can't get executed unless intentionally by the idiot writing the receiving end.
> an attacker will only be able to manipulate the content of some environment variable, but not its name.
How can this be true?
I just tried and successfully passed the variable "_BASH_FUNC_thingy" with the value "my_attack" through my apache web server to a CGI script using a url entered into a browser.
That forcing Google apps discourages OEM bloat is simply an assumption.
No. OEM bloat is directly tied to shipping old version of Android. The OEM bloat takes time to build and test and qualify for release. Thus this happens on an earlier version of Android. While the development is taking place, Android is moving on too.
If you take the vanilla Android, you can release a much more up-to-date version, since you don't need 6 months to 1 year to update and requalify your bloatware with the new version of Android. This is pretty much the value proposition of Nexus over any other brand.
Building complex apps without coding doesn't seem like a useful goal. At some point you have to express the program logic and coding has always proven to be the best way.
The dividing line between graphical tool and actual code seems to have been a shifting one over the years. So when you go to a new environment or language where there's a substantial GUI component to building an app, the desire to see it all in code is strong. What actually happens when you add that button? I expect to be able to do it either through code of GUI and if they can't tell me what the GUI did in code, then I'm left clueless as to the underpinnings and so it becomes hard to think through the implications of design decisions.
I tried Swift recently. Swift was easy enough. But Swift+Xcode was impenetrable.
When a company moves from innovating to abusing its market share, it's usually not a good sign.
Except when you get a phone with an old version of Android and loads of proprietary bloatware 'innovation' the phone sucks in ways it would not suck if it just had the up-to-date integrated Google app suite and android versions.
In this instance, the more Google succeeds, the better the products are.
Slashdot Mirror
Mega volcano?
Does TFA mean a big volcano or a million volcanos?
>Every protocol that runs over RS232
Protocols that run over RS232 are not RS232. RS232 is the interface spec.
I've worked on-and-off in healthcare and the standards for transmitting *anything* are ancient and bad. Formats like HL7 and ASTM are ancient delimited-text formats with no UTF-8 support, no encryption, and even have RS232 ACK/NAK packets in the standard.
RS232 didn't have packets. It had wires. It didn't have ACK/NACK either. It had CTS/RTS and DCR/DTR. There were some secondary signals (STD, SRD etc) that were rarely implemented after 1980.
>If anything, this is nothing more than an industry standards issue.
Get IEEE 802 to do it.
You'd be able to pass your medical records through an 802.1D compliant bridge transparently, with or without Q.
it is against the law to transport it across state lines though
Does it or its owner become suddenly more dangerous after crossing a state line?
I just tried and successfully passed the variable "_BASH_FUNC_thingy" with the value "my_attack" through my apache web server to a CGI script using a url entered into a browser.
No, you get something like QUERY_STRING="_BASH_FUNC_thingy=my_attack", which is harmless because function definitions inside QUERY_STRING are not being evaluated after the last update.
No I didn't. I'll play with bash versions and see if there was a change. I don't think so though.
I have lived the ASN.1 horror. I will kill it. I will show no mercy. Know this, for it is true.
They will try to put CALEA crap in by default with no option to turn off.
But jar jars blink.
Fortunately for the evil doers, they don't have to be bound by past vulnerabilities.
Just give it a name that the script already uses.
If the script uses functions passed through the environment variables, it is now going to be written such that those variable names are prefixed with _BASH_FUNC_ because the new changes require it. So the attacker follows suit. The point being that the attacker can indeed modify the name and he or she or it can modify it to suit the script being attacked.
The underlying problem is using environment variables (I.E. data) that get executed by the interpreter. Don't do that. You can write CGI programs that are invulnerable, but you can't be sure every CGI program in every bit is system and web bloatware is invulnerable.
Better to fix CGI. Give it a new interface. E.G. It calls the program and hands it a pointer to a file that contains the variables. Or uses any other form of IPC. Just make sure it can't get executed unless intentionally by the idiot writing the receiving end.
>that setting a variable whose name starts with _BASH_FUNC_ is going to be nigh impossible through a standard HTTP interface.
But that's exactly what I did by appending ?_BASH_FUNC_thingy=myattack to a url to a CGI script.
The telecoms would add X25d with ASN.1 line coding to systemd if they could get away with it.
So they're stuck to the bottom of the screen?
Can they be ajar?
The telecoms contributors will play dirty. I promise you.
> an attacker will only be able to manipulate the content of some environment variable, but not its name.
How can this be true?
I just tried and successfully passed the variable "_BASH_FUNC_thingy" with the value "my_attack" through my apache web server to a CGI script using a url entered into a browser.
> it has to be prefixed with _BASH_FUNC_ in order to be allowed as a definition)
What's stopping me passing _BASH_FUNC_ in a HTTP request to a BASH CGI script?
Is a re-sizable tile like a window?
>So you're saying it's a case of, "Google, products so good you need to be forced to use them?"
No. I'm saying the other stuff other manufacturers put on phones is a lot worse.
If they can make something lots better, then that alters the equation. Hence Tizen, Meego etc. I'm not holding my breath.
" a man walked past a Sydney Airport security screening while engrossed in his iPad and delayed flights for an hour."
TFA implies he caused the delay, when in fact incompetent airport security staff caused the delay.
That forcing Google apps discourages OEM bloat is simply an assumption.
No. OEM bloat is directly tied to shipping old version of Android. The OEM bloat takes time to build and test and qualify for release. Thus this happens on an earlier version of Android. While the development is taking place, Android is moving on too.
If you take the vanilla Android, you can release a much more up-to-date version, since you don't need 6 months to 1 year to update and requalify your bloatware with the new version of Android. This is pretty much the value proposition of Nexus over any other brand.
Building complex apps without coding doesn't seem like a useful goal. At some point you have to express the program logic and coding has always proven to be the best way.
The dividing line between graphical tool and actual code seems to have been a shifting one over the years. So when you go to a new environment or language where there's a substantial GUI component to building an app, the desire to see it all in code is strong. What actually happens when you add that button? I expect to be able to do it either through code of GUI and if they can't tell me what the GUI did in code, then I'm left clueless as to the underpinnings and so it becomes hard to think through the implications of design decisions.
I tried Swift recently. Swift was easy enough. But Swift+Xcode was impenetrable.
And if Microsoft required something similar, you'd be crying the same thing, right?
What's good for the goose is good for the gander.
No. The problem with Microsoft was the Office lock-in with proprietary file formats.
When a company moves from innovating to abusing its market share, it's usually not a good sign.
Except when you get a phone with an old version of Android and loads of proprietary bloatware 'innovation' the phone sucks in ways it would not suck if it just had the up-to-date integrated Google app suite and android versions.
In this instance, the more Google succeeds, the better the products are.
I'm screwed. I live in one and travel to the other on a fairly regular basis.
>What kind of an admin are you?
The best kind: Grumpy.