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