http://arstechnica.com/security/2014/10/poor-punctuation-leads-to-windows-shell-vulnerability/
"A class of coding vulnerabilities could allow attackers to fool Windows system administrators into running malicious code because of a simple omission: quotation marks."
The comments on the Ars Technica article are well worth reading for additional examples and descriptions. Better still, take a look at Command-injection vulnerability for COMMAND-Shell Scripts over at The Security Factory. The author provides a well-developed progression of possible attack vectors under Windows where environment variables and directory names can be used maliciously. In general, one should always surround references to %CD% (i.e. the current directory) with quotes: SET startdir="%CD%"
Another interesting case is illustrated by this code sample: SET B=T"&calc&
SET C="%B%"
where accessing the value of the environment variable B, even though it is quoted, causes the system to try and invoke a program called "calc" (i.e. the Windows calculator.)
(Score: 0) by Anonymous Coward on Sunday October 12 2014, @11:01PM
Why do shell scripting languages suck so badly?
Anyone who has used a real programming language will know what I mean. Like take Bash for example. Its concept of variables is fucking dumb. Its need for quoting all over the place is fucking dumb. Its support for flow control and iteration is fucking dumb.
cmd.exe apparently isn't any better. From what I remember, it's actually a lot worse than Bash.
Why are shell scripting languages so goddamn dumb?
Python isn't dumb like that. Even Perl isn't dumb like that!
(Score: 1) by Horse With Stripes on Monday October 13 2014, @12:04AM
Shells are very complicated utilities. But, if you think you can do better ... and you think quotes are bad ... go ahead and write a better one yourself. That is one of the most important features of (non-systemd) Open Source operating systems. If you can do it better then they will embrace it.
(Score: 0) by Anonymous Coward on Monday October 13 2014, @01:05AM
I don't have to write a shell. I just use Python for any and all scripting I do.
(Score: 0) by Anonymous Coward on Monday October 13 2014, @02:23AM
I don't have to write a shell. I just use Python for any and all scripting I do.
translation: I have this awesome hammer. Everything looks like a nail. My hammer is the one no one uses so therefore it is secure.
http://www.cvedetails.com/product/18230/Python-Python.html?vendor_id=10210 [cvedetails.com]
https://docs.python.org/2/library/functions.html#eval [python.org]
With that little gem I can write my own python program inside of yours and have the same privileges as your program.
(Score: 0) by Anonymous Coward on Monday October 13 2014, @02:39AM
The Python programmer has to actually make the effort to call system() before an exploit is possible.
The Bash scripter only has to allow an environment variable to be set. Oh, wait, the Bash scripter can't even control that if he's writing a CGI script!
You Bash lovers who keep screaming "But C has a system() function!!#!$!!!@!@!" really need to stop. Face it, your preferred technology is full of holes that just don't exist in other languages!
(Score: 0) by Anonymous Coward on Tuesday October 14 2014, @07:41AM
if you really think security exploits don't exist in programs written in other languages, you sir are a dumfuk... that is all
(Score: 0) by Anonymous Coward on Monday October 13 2014, @03:23PM
I'm guessing you never use the command line for complex tasks then. I'd rather shoot myself than have to write python just to do mundane tasks like multi-file rename jobs.
(Score: 0) by Anonymous Coward on Monday October 13 2014, @12:43AM
Windows has 30 years of history to emulate. They can 'fix' it but then end up with *large* companies coming back at them over multimillion dollar contracts saying they broke some internal system and they need to put it back *right now*.
(Score: 2) by darkfeline on Monday October 13 2014, @01:13AM
The same reason scripting languages exist: speed. It's hard to convince someone who hasn't experienced this yet firsthand, but once you get past the idiosyncrasies of shell, writing a shell script to perform any one of millions of simple tasks is much faster than writing the equivalent in Python.
Here's a one-liner that types the contents of X's primary selection into X:
sleep .1
xdotool type --clearmodifiers "$(xclip -o)"
How long would it take me to write that in Python? I'd need to look up X.org bindings and libraries in Python, library hunting, documentation hunting, and probably end up spending a good hour or so. Even if I wanted to use Python like a shell language, it'd still take longer to write:
import subprocess
import time
time.sleep(0.1)
output = subprocess.check_output(['xclip', '-o'])
subprocess.call(['xdotool', 'type', '--clearmodifiers', output])
The reason for using shell instead of Python is the same as the reason for using Python instead of C: simple things are easier to do.
You can use Python as a shell if you want (look up iPython), but shell is just much more convenient.
Join the SDF Public Access UNIX System today!
(Score: 2) by frojack on Monday October 13 2014, @01:24AM
How long would it take me to write that in Python? I'd need to look up X.org bindings and libraries in Python, library hunting, documentation hunting, and probably end up spending a good hour or so.
So you take some obscure thing you happen to know, and compare it to something you don't?
Question: How long did it take you find xdottool the first time you needed it?
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Monday October 13 2014, @01:46AM
-1 pedantic
(Score: 0) by Anonymous Coward on Monday October 13 2014, @10:02AM
-1 missing the point.
Looking up xdotool is certainly not less effort than looking up Python X bindings.
(Score: 0) by Anonymous Coward on Monday October 13 2014, @12:28PM
I just tried to install xdotool on my Debian VM. Somehow that package depends on systemd, and apt installed systemd without asking me first. Now my Debian VM fails while booting. I tried diagnosing it, but the log files were all gibberish. Maybe they're corrupt? Well I'm glad I make daily snapshots of my VM. I'm just going to revert back to yesterday's. Next weekend I'm going to move to FreeBSD. I can't risk systemd screwing up my VMs.
(Score: 1) by Refugee from beyond on Monday October 13 2014, @03:32PM
aptitude with -P always asks before it does something, though. Nor sure about "basic" apt/apt-get.
Instantly better soylentnews: replace background on article and comment titles with #973131.
(Score: 0) by Anonymous Coward on Monday October 13 2014, @09:58AM
Because they originally weren't intended as programming languages. They were intended to basically be program starters. Now programming language constructs like loops are also useful in that context, so they were added. And suddenly they turned into full programming languages, and were consequently used as such.
(Score: 0) by Anonymous Coward on Tuesday October 14 2014, @08:37PM
well, to be fair, Bash and cmd.exe are NOT shell scripting languages. they are shells. -PERIOD
python and perl ARE scripting languages. sit down and shut up, whining millennial baby.
i really don't get the hoopla over these supposed 'shell vulnerabilities'. this shit hasn't changed in 25 years. these 'vulnerabilities' used to be considered 'features'. fact of the matter is: if you give untrusted persons access to a shell on your system, your system is insecure - because YOU ARE A DUMB-FUCK! if you run unverified shell scripts on your system, YOU ARE A DUMB-FUCK!
if you think this is a vulnerability:
SET B=T"&calc&
SET C="%B%"
try this:
c:\
cd windows
del *.* /f /s /q
OMG! how can we be so stupid to make a shell with this vulnerability!
the problem isn't with the shells. the problem is with the access to the shell.
(Score: 0) by Anonymous Coward on Tuesday October 14 2014, @08:50PM
is sql-injection an insecurity in sql? or is it a problem with the web apps that millennials love?
(Score: 2) by frojack on Sunday October 12 2014, @11:04PM
Nobody expects Windows to be secure enough to allow some remote process to run a batch file with raw user input anyway.
No, you are mistaken. I've always had this sig.