Friday, September 26, 2014

Shellshock Bash Exploit in Windows

Searching for bash.exe in Windows, I found several instances of Bash, all of which were vulnerable to the Shellshock exploit. Anyone who develops programs or web applications in Windows may have one or more instances of Bash. Anyone who uses Git in Windows almost certainly will have at least one.

First, I used the Windows File Explorer to search each disk drive for instances of “bash.exe”.

Then, using some advice from Scott Simpson at, I ran the following commands:

cd <directory containing bash.exe>
bash-3.1$ env x='() { :;}; echo vulnerable' bash -c "echo done
done running

I also tested “sh.exe” the same way, in case it happened to be just a copy of “bash.exe”.

Here are the places where I found “bash.exe” on my development machine. You may find similar ones on yours.

1.) C:\Program Files (x86)\Git\bin\bash.exe
    GNU bash, version 3.1.0(1)-release (i686-pc-msys)
    C:\Program Files (x86)\Git\bin\sh.exe
    GNU bash, version 3.1.0(1)-release (i686-pc-msys)
2.) C:\DevKit\bin\bash.exe
    GNU bash, version 3.1.17(1)-release (i686-pc-msys)
    GNU bash, version 3.1.17(1)-release (i686-pc-msys)  
3.) C:\MinGW\msys\1.0\bin\bash.exe
    GNU bash, version 3.1.17(1)-release (i686-pc-msys)
    GNU bash, version 3.1.17(1)-release (i686-pc-msys)
4.) C:\Users\<user>\AppData\Local\GitHub\PortableGit…\bin\bash.exe
    GNU bash, version 3.1.0(1)-release (i686-pc-msys)
    GNU bash, version 3.1.0(1)-release (i686-pc-msys)

Every one of these turned out to be vulnerable, even though most had been installed recently. I haven’t yet found a Windows version of “bash.exe” patched to prevent the Shellshock exploit.

In practice, my system probably isn’t actually vulnerable to this particular exploit since I don’t normally run any server that executes CGI scripts, plus my firewall prevents incoming requests on the ports used by my servers in development mode. It’s only a development machine, not a production one.

An additional precaution is that none of the paths in my default Windows PATH variable permit bash.exe to be run. You easily can test this on your own machine: Start the Windows command console, cmd.exe. and type “bash”. If it runs, probably not a good thing. If  it fails to run, so much the better.

There is a patch available for other operating systems that is discussed here:

Thursday, September 18, 2014

Git Cheat Sheet

Here are just a few Git commands that you will want to know if you are going to use Git to manage source file versions.

git help
Gets a list of all the git commands.

git help <command>
Gets help for the given command.

git init
Initializes a directory with a local repository so that you can start using git there. No need to use this command if you are going to clone an existing remote repository (see below).

git remote -v
Lists remote repositories for current project.

git clone <repository> <target-directory>
Gets a copy of the source code from the given repository and puts
it in the given directory. An example repository would be 
The <target-directory> is optional. If you omit it, git will put the cloned code in a subdirectory named after the repository (e.g., ‘node-redis-queue’ in the above link).

git pull –no-commit origin
Gets the latest changes from the given remote repository and merges them with the  local source code. “—no-commit” specifies to leave the changes uncommitted so that you can examine them with “git diff”. By default the changes automatically are committed.

git status
List staged files and all other changed files.

git add <filename>
Stage the given file, which means it is ready to commit.

git commit -m "My comment"
Commit the staged files to the local repository.

git commit -am "My comment"
Adds and commits all modified files to the local repository. Ensure you have your .gitignorerc file set up correctly before using this shortcut.

git commit --amend
Need to fix the mistake you made in the comment for the latest commit? This brings up your default editor, where you can change the comment in the first few lines, save and then exit the editor.

git checkout <file-name>
Gets the latest copy of the given file out of the local repository and may overwrite the file of the same name in your working directory. You can use this to discard local changes you no longer want, provided you haven’t yet staged or committed them.

git reset <file-name>
Need to discard some local changes that you’ve already staged (e.g., via git add) but not yet committed ? This is how to do it.

git reset --hard
Need to discard all local changes whether you have staged them or not ? This is how to do it.

git checkout -b <branch-name>
Create a branch with the given name and switch to that branch.

git checkout <branch-name>
Switch to the code in the given branch, which must already exist. Very fast. But ensure you have committed your current code changes before switching.

git push --set-upstream origin <branch-name>
Use this the first time you push some code changes to your new branch. It creates an upstream branch. It sets up the branch to track the remote branch from origin.

git push origin <tag-name>
Pushes the local changes (optionally identified by the tag) up to the remote repository identified by origin. The tag-name is optional.

git push –tags origin master
Pushes the local changes and all tags up to the remote repository identified by origin and makes them part of the master branch.

git merge -X theirs <branch-name>
Merges the given branch into the current branch, preferring changes from the given branch. If “-X theirs” is omitted, then preference is given to the current branch.

git fetch origin master
git reset --hard origin/master

git pull origin master
Want to throw away your already committed local changes in the local master branch? The first command fetches the commits from the remote repository. The second command positions your working copy to the tip of the master branch. All your local commits are discarded. The third command ensures you really have all the latest master code. Of course, you can substitute a different branch name for ‘master’. Doesn’t disturb the other branches in your local repository.

git push --tags
No tags in your remote repository? Then, use this command to push all of them there.

git tag -l
Lists the tags in the local repository.

git tag <tag-string>
Tags the files in the local repository with the given tag.

git tag -d <tag-string> <optional-file-name>
Deletes the given tag (optionally from the given file).

git log <file-name>
Lists all commits in the local repository. The file-name is optional. If present, then you get the log just for that file.

git show <branch-name>~<n-back>:<file-name>
Shows the state of the given file <n-back> commits back. For example:
git show master~1:package.json
shows the previous revision of the file package.json in the master branch.

git show <tag-string> – <file-name>
For example:
git show v0.1.3 -- package.json
which is similar to
git diff v0.1.2 v0.1.3 -- package.json.
but also shows commit comments, which is quite useful. The file name may be omitted. For example,
git show v0.1.3

git diff <branch-name>
Compares the current branch to the given branch.

git diff <branch-name>~<n-back>:<file-name> <file-name>
Need to compare a given file with a revision previously commited? For example,
git diff
specifies to compare the revision 3 revisions back with the current local version of

To compare two previously committed revisions, one would do something like:
git diff

git diff <branch-name>~<n-back>:<file-name> <file-name>
Need to compare a given file with a revision previously commited? For example,
git diff 
compares the revision 3 revisions back with the current local version of

To compare two previously committed revisions, one would do something like:
git diff

git diff <tag> – <file-name> 
Compares the given file revision having the given tag with the current local version of the file. For example,
git diff v0.0.3 -- package.json
compares the package.json file having tag v0.0.3 with the current local version of

To compare two previously committed revisions having different tags, one would do something like:
git diff v0.0.2 v0.0.3 -- package.json

git update-index --chmod=+x <file-name>
Do you find after a deploy that git did not have the correct permissions for one of your files? You can change the executable permission this way. Use “+x” to set execute permission or “-x” to remove it.