Comment Mega? (Score 1) 33
Mega volcano?
Does TFA mean a big volcano or a million volcanos?
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.
The key elements in human thinking are not numbers but labels of fuzzy sets. -- L. Zadeh