Ever saw a WiFi base station named "| rm -rf ~ | rm -rf /?
When scripting some kind of simple analysis or logging of WiFi base station data, how would one ensure that an attacker won't be able to inject shell commands into your expressions?
For example, I want to log data from ifconfig run0 scan on OpenBSD and airport -s on OS X, and I already have some scripts in sh/tcsh that work great for my needs. But how could I ensure that I don't become a victim of shell injections?
this problem has been addressed to the OpenBSD lists (misc#) many times, as well as in other places.
first of all i would advise you to NOT execute things that you get from the network, specially in a script. Maybe you can edit your question to be more specific on what you want to do with these data so our answers could be tailored to it.
if you want to use this info to connect to networks (as a network manager), put yourself between the script and the input. So after getting the output of scan just copy the nwid that you approve in your actual script. check out this discussion on undeadly
if you need to run automated scripts on the input for some other purpose (data gathering?), consider creating a chrooted dir , with your script and your statically compiled shell in it and run it chrooted. Of course you shouldn't rely on that approach for more sophisticated attacks than the one you mentioned in your question.
Hope this helps.
Related
If you were hypothetically writing a web service that checks the syntax of bash files, would there be any security concerns to running bash -n on any user input?
As near as I can tell, -n should work as you expect, and yet I would still be cautious: I'm not aware of any serious examination of using bash -n for syntax-checking untrusted code, and bugs in bash or in your C library, or really anywhere could have effects here that may be exploitable in ways that may be difficult to reason about.
It's always seemed prudent to never trust user input, and a big codebase like bash is a big place to hide bugs.
Here's what I would do:
Prepare a chroot jail to run a statically-linked restricted bash
Prepare a non-root user for purposes
Write a script that constructs the jail from a template, chroots in with the source file, drops privileges, closes all fds except (1) and dups (2) to it, then finally runs bash -n with your program.
This may sound like a silly question but up until recently if you tried to unmount a volume that was in use the Finder reported that it was in use, but not by whom. This is simple Unix functionality, if a file is open on a mount point, do not allow it to eject. But now they seem to have added functionality that lets the user know what programs are currently using a mounted system, and I have been looking through man pages of fopen,stat, etc. for Unix like operating systems(distros of linux) and I can't seem to find similar functionality.
Is this functionality specialized, or am I just looking in the wrong place?
There are BSD-level calls (mainly lsof, whose source is at http://www.opensource.apple.com/source/lsof/) that let you examine the list of files open in a process. Activity Monitor, for example, uses them.
Using lsof as a starting point, you can iterate through processes and see if any of them are using a file under the mount point you're examining. There may be more efficient ways to do it though, of which I'm not aware. :)
It's somewhat specialized. Check out the lsof utility.
Check the man page for fuser, and run fuser -c /mountpoint
my goal: to create a suite of scripts that do some common system tasks, which include these
copy/move/list/search/grep files
watch/start/stop processes
run queries against Oracle via sqlplus
i grew accustomed to using Cygwin/bash to ease my life at work, and frankly speaking, i don't want to move away from bash language and start learning PowerShell, for example - so i started searching for a way to run bash scripts on Windows, ... preferably something alternative to Cygwin.
the truth is that i am still not pleased with Cygwin installation, and the fact that there is no simple way around it, that it is targeting more or less expert users, and there are a number of things that might pop up during the installation. i mean. what i am trying to do now is to write a suite of scripts that will target someone less expert than me (and i am in no way a real expert) - in most cases some kind of an administrator who doesn't want to know the script details.
i am thinking that this user will also want to be able to run these scripts on another machine, and i want to be able to explain him/her how to do it, without just saying, call the support, and, me, eventually (so that we can install cygwin on another machine etc etc.)
i tried MinGW(msys) but it also needs manual steps to set things up - i mean, these manual steps have become something of a de facto standard in these Windows ports (sorry, maybe i have a mood for bragging). win-bash looked like it could be a solution, but i ended up trashing it too, because of the old bash version, and its inability to do things i was able to do in cygwin - specifically
here documents
things like "cmd /C dir *" (don't know why) - and yes, i do cmd /C dir in cases i am in some kind of shared network folder with thousands of files, and ls is significantly slower than dir
my questions at last:
am i doomed to use PowerShell? i guess i will, reluctantly, if i have to
is there a simple pre-packaged "slim" cygwin installation.. or, portable cygwin, even better? there is a cygwin-portable project on sourceforge, but it's not that doesn't need those manual steps, again, apparently - is there a way to automate those steps, perhaps? and if there is, i wonder why somebody hasn't done it already? - and then, would it be possible to call bash scripts from Windows command prompt using a simple command like "bash somescript.sh"?
thanks for your attention.
As mentioned here, the Cygwin installation can totally be scripted and parametrized to ran in a silently and automatic mode.
If you define the minimal list of cygwin packages you need, just use a little .bat script that call the cygmin setup executable like this
setup.exe --packages=list_of_packages_you_need --quiet-mode
If you wrap the cygwin install process, it should be tolerable for a less technical user.
The cygwin install can be streamlined using command-line args;
http://sources.redhat.com/ml/cygwin-apps/2003-03/msg00526.html
You can also automate the install of most cygwin packages through cyg-apt.
I haven't verified this but I suspect that msys implements a *nix look alike by creating windows executable versions of system commands. All of the common commands have an executable on my install of msys. If that is true then it should be possible to use them separate from a complete install.
Try copying "bash.exe", "cp.exe", etc. from the msys bin directory to a machine/vm that does not have an msys install and see if it works. You may need to copy some dll's or shared libraries as well. A windows dependency checker program would show which dll's an executable is using.
You could package up the stuff you use and make a simple installer or just copy the files with your scripts.
Take a look at MKS Toolkit. Unlike Cygwin, it can live within the Windows world. Files end in CR/LF like Windows files, and you don't have that /cygdrive/c stuff. Naked drive letters work fine in MKS Toolkit.
A few caveats:
I haven't used MKS Toolkit in a long time. See following reason.
MKS Toolkit is (sit down for this) $600 per license. Ouch! That's why I use Cygwin even though I don't think it's as good or works as well.
It's Kornshell based and not Bash (although this may be a bit different). Kornshell and BASH are 95% alike. However, that last 5% gets you. I actually like Kornshell better than BASH in many respects. Kornshell has the print statement which is way superior than the echo statement. Variable names don't disappear in blocks. You can easily do double loops because almost all the commands can take unit numbers of input and output. However, Kornshell doesn't have those neat escape characters in the prompt, and it's hard to find the exit status of a command in the middle of the pipeline.
I don't know if this is a dumb question or not but again as my professor says if you have doubts then clear them . What is the difference between Linux text mode and windows command prompt (cmd). I know both windows and Linux are different Operating Systems but when you look at the commands, some of the commands are common For Example cd command.
Although superficially similar in some ways, the two command line interfaces have different lineages:
The Windows command prompt is based heavily on that of MS-DOS / PC-DOS, which in turn was based on the CP/M Console Command Processor. The CP/M CCP interface was itself based on an earlier operating system called RSTS.
The Linux shells trace their roots back to the original UNIX Thompson shell; the Thompson shell borrowed from the Multics shell (where the term "shell" originated).
Traces of these are still evident today - the DIR command in the Windows command prompt can be traced all the way back to the DIR command in RSTS, and similarly the ls command in GNU coreutils can be traced back to the Multics "list segments" command.
They're both based on the same idea and are called Command-Line Interfaces (see wikipedia). They operate off the same principals, just using different keywords to perform similar commands. It should be noted however, that the commands although similarly named, may not perform the exact same function. They are just abstractions of lower level functions of the operating system. Just like people can explain similar ideas using different words and phrases, the same applies in this situation. For reference here's a list of Bash commands: http://ss64.com/bash/ and the same website has windows commands.
The difference is the operating system. The command prompt (cmd) and a terminal emulator (linux bash shell or similar) are text interfaces to the operating system. They allow you to manipulate the file system and run programs without the graphical interface.
You should read about Linux shells. The Bash shell for instance, is among the most used Linux shells... ever!
http://doc.dev.md/lsst/ch01sec07.html
http://www.tuxfiles.org/linuxhelp/shell.html
And if you're looking for a list of commands: http://www.physics.ubc.ca/mbelab/computer/linux-intro/html/
It is not that commands are in common (well yes, maybe some), it is that they have the same name and do almost the same things, as for cd as you said.
The shells are an abstraction of the underlying operative system, Linux and Windows have a different kernel, hence the difference.
You might want to start here with your reading.
If while an application is running one of the shared libraries it uses is written to or truncated, then the application will crash. Moving the file or removing it wholesale with 'rm' will not cause a crash, because the OS (Solaris in this case but I assume this is true on Linux and other *nix as well) is smart enough to not delete the inode associated with the file while any process has it open.
I have a shell script that performs installation of shared libraries. Sometimes, it may be used to reinstall versions of shared libraries that were already installed, without an uninstall first. Because applications may be using the already installed shared libraries, it's important the the script is smart enough to rm the files or move them out of the way (e.g. to a 'deleted' folder that cron could empty at a time when we know no applications will be running) before installing the new ones so that they're not overwritten or truncated.
Unfortunately, recently an application crashed just after an install. Coincidence? It's difficult to tell. The real solution here is to switch over to a more robust installation method than an old gigantic shell script, but it'd be nice to have some extra protection until the switch is made. Is there any way to wrap a shell script to protect it from overwriting or truncating files (and ideally failing loudly), but still allowing them to be moved or rm'd?
Standard UNIX file permissions won't do the trick because you can't distinguish moving/removing from overwriting/truncating. Aliases could work but I'm not sure what entirety of commands need to be aliased. I imagine something like truss/strace except before each action it checks against a filter whether to actually do it. I don't need a perfect solution that would work even against an intentionally malicious script.
You can prevent a script from overwriting through I/O redirection by
set noclobber
Preventing overwriting by cp and the like is harder. My inclination would be to reset the PATH for the script to run with PATH containing just a single entry, a "blessed" directory where you place commands that you know are safe. This might mean, for example, that your version of cp is arranged always to use the --remove-destination option (probably a GNU-ism). In any case, you arrange for the script to execute only commands from the blessed directory. You can then vet each such command individually.
It would be good if you could prevent a script from executing a command by absolute pathname, but I don't know how to do that. If you are doing installations in your regular directories, a chroot jail probably does not help unless you do a lot of loopback mounting to make those directories visible. And if the directories into which you're installing contain dangerous commands, I don't see how you can protect yourself against them completely.
Incidentally, I tried and failed to learn if install(1) removes the desitination before installing. It would be interseting to learn.
Bash script I presume? Is the script very long? If not, you can do this manually:
if [ ! -f /tmp/foo.txt ] #If file does not exist
then
...code
fi
But I think you're asking for a way to wrap this around the script. You can certainly monitor the file writes with strace but AFAIK it doesn't have the functionality to interrupt them, unless you set up some sort of Intrusion Detection System with rules etc.
But to be honest, unless it's a huge script, that's probably more trouble than it's worth
Write your own safe_install() functions and make sure they're the only methods used. If you really need to be sure, run two processes. One would have permissions to make changes and the other would drop all privileges early and tell the other script to do the actual disk work.