My apologies if you speak the Queen’s English since that title probably has a whole different meaning to you than I intended. In fact, I’m talking about Git, the version control system. Last time I talked about how the program came to be and offered you a few tutorials. If you are a dyed-in-the-wool software developer, you probably don’t need to be convinced to use Git. But even if you aren’t, there are a lot of things you can do with Git that don’t fit the usual mold.
Git is one of those tools that is so simple to use, that you often don’t learn a lot of nuance to it. You wind up cloning a repository from the Internet and that’s about it. If you make changes, maybe you track them and if you are really polite you might create a pull request to give back to the project. But there’s a lot more you can do. For example, did you know that Git can track collaborative Word documents? Or manage your startup files across multiple Linux boxes?
Git belongs to a family of software products that do revision (or version) control. The idea is that you can develop software (for example) and keep track of each revision. Good systems have provisions for allowing multiple people to work on a project at one time. There is also usually some way to split a project into different parts. For example, you might split off to develop a version of the product for a different market or to try an experimental feature without breaking the normal development. In some cases, you’ll eventually bring that split back into the main line.
Although in the next installment, I’ll give you some odd uses for Git you might find useful, this post is mostly the story of how Git came to be. Open source development is known for flame wars and there’s at least a few in this tale. And in true hacker fashion, the hero of the story decides he doesn’t like the tools he’s using so… well, what would you do?
We’ve always been a fans of wargames. Not the movie (well, also the movie) but I’m referring to hacking wargames. There are several formats but usually you have access to an initial shell account somewhere, which is level0, and you have to exploit some flaw in the system to manage to get level1 permissions and so forth. Almost always there’s a level where you have to exploit a legitimate binary (with some shady permissions) that does more than what the regular user thinks.
In the case of CVE-2017-8386,
less is more.
[Timo Schmid] details how the
git-shell, a restricted shell meant to be used as the upstream peer in a git remote session over a ssh tunnel, can be abused in order to achieve arbitrary file read, directory listing and somewhat restricted file write. The
git-shell basic idea is to restrict the allowed commands in an ssh session to the ones required by git (git-receive-pack, git-upload-pack, git-upload-archive). The researcher realized he could pass parameters to these commands, like the flag –help:
$ ssh git@remoteserver "git-receive-pack '--help'" GIT-RECEIVE-PACK(1) Git Manual GIT-RECEIVE-PACK(1) NAME git-receive-pack - Receive what is pushed into the repository [...]
What the flag does is make the git command open the man page of git, which is passed on to a pager program, usually
less. And this is where it get interesting. The
less command, if running interactively, can do several things you would expect like searching for text, go to a line number, scroll down and so on. What it can also do is open a new file (:e), save the input to a file (s) and execute commands (!). To make it run interactively, you have to force the allocation of a PTY in
ssh like so:
$ ssh -t git@remoteserver "git-receive-pack '--help'" GIT-RECEIVE-PACK(1) Git Manual GIT-RECEIVE-PACK(1) NAME git-receive-pack - Receive what is pushed into the repository Manual page git-receive-pack(1) line 1 (press h for help or q to quit)
Press h for help and have fun. One caveat is that usual installations the code execution will not really execute arbitrary commands, since the current running login shell is the
git-shell, restricted to only some white listed commands. There are, however, certain configurations where this might happen, such as maintaining
sh as a login shell and limit the user in ways that they can only use
git (such as in shared environments without root access). You can see such example here.
The quickest solution seems to be to enable the
no-pty flag server-side, in the
sshd configuration. This prevents clients from requesting a PTY so
less won’t run in an interactive mode.
$ man less LESS(1) General Commands Manual LESS(1) NAME less - opposite of more
Ironic, isn’t it?
Has work been a little stressful this week, are things getting you down? Spare a thought for an unnamed sysadmin at the GitHub-alike startup GitLab, who early yesterday performed a deletion task on a PostgreSQL database in response to some problems they were having in the wake of an attack by spammers. Unfortunately due to a command line error he ran the deletion on one of the databases behind the company’s main service, forcing it to be taken down. By the time the deletion was stopped, only 4.5 Gb of the 300 Gb trove of data remained.
Reading their log of the incident the scale of the disaster unfolds, and we can’t help wincing at the phrase “out of 5 backup/replication techniques deployed none are working reliably or set up in the first place“. In the end they were able to restore most of the data from a staging server, but at the cost of a lost six hours of issues and merge requests. Fortunately for them their git repositories were not affected.
For 707 GitLab users then there has been a small amount of lost data, the entire web service was down for a while, and the incident has gained them more publicity in a day than their marketing department could have achieved in a year. The post-mortem document makes for a fascinating read, and will probably leave more than one reader nervously thinking about the integrity of whichever services they are responsible for. We have to hand it to them for being so open about it all and for admitting a failure of their whole company for its backup failures rather than heaping blame on one employee. In many companies it would all have been swept under the carpet. We suspect that GitLab’s data will be shepherded with much more care henceforth.
We trust an increasing amount of our assets to online providers these days, and this tale highlights some of the hazards inherent in placing absolute trust in them. GitLab had moved from a cloud provider to their own data centre, though whether or not this incident would have been any less harmful wherever it was hosted is up for debate. Perhaps it’s a timely reminder to us all: keep your own backups, and most importantly: test them to ensure they work.
Thanks [Jack Laidlaw] for the tip.
Rack server image: Trique303 [CC BY-SA 4.0], via Wikimedia Commons.
Secret keys are quite literally the key to security in software development. If a malicious actor gains access to the keys securing your data, you’re toast. The problem is, to use keys, you’ve got to write them down somewhere – oftentimes in the source code itself. TruffleHog has come along to sniff out those secret keys in your Github repository.
It’s an ingenious trick — a Python script goes through the commit history of a repository, looking at every string of text greater than 20 characters, and analyzing its Shannon entropy. This is a mathematical way of determining if it looks like a relatively random string of numbers and letters. If it has high entropy, it’s probably a key of some sort.
Sharing source code is always a double-edged sword for security. Any flaws are out for all to see, and there are both those who will exploit the flaws and those who will help fix them. It’s a matter of opinion if the benefits outweigh the gains, but it’s hard to argue with the labor benefits of getting more eyes on the code to hunt for bugs. It’s our guess though, that a lot of readers have accidentally committed secret keys in a git repository and had to revert before pushing. This tool can crawl any publicly posted git repo, but might be just as useful in security audits of your own codebase to ensure accidentally viewable keys are invalidated and replaced.
For a real world example of stolen secret keys, read up on this HDMI breakout that sniffs HDCP keys.
[mfaust] wakes up in the morning like a regular person, goes to work like a regular person, types in tedious commands for his software versioning utilities like a regular person, and then, as a reward, gets his coffee, just like rest of us. However, what if there was a way to shorten the steps, bringing us all closer to the wonderful coffee step, without all those inconvenient delays? Well, global industry is trying its best to blot out the sun, so mornings are covered there. [Elon Musk’s] thinktank proposed the hyperloop, which should help with the second step. [mfaust] built a control station for his versioning software. Raise your cup of joe high for this man’s innovative spirit.
He first laid out all the buttons, LED lights, and knobs he’d like on a panel to automate away his daily tasks. Using photoshop he ended up with a nice template. He laminated it to the top of a regular project box and did his best to drill holes in the right places without a workshop at his command. It’s pretty good looking!
Since this is the sort of thing an Arduino is best at he, in a mere two tries, wired everything up in such a way that it would all cram into the box. With everything blinking satisfactorily and all the buttons showing up on the serial out, he was ready for the final step.
Being a proficient and prolific enough developer to need a control panel in the first place, like a sort of software DJ, he wrote a nice interface for it all. The Arduino sits and waits for serial input while occasionally spitting out a packet of data describing its switch status. A Java daemon runs in the background of his computer. When the right bits are witnessed, a very nicely executed on screen display reports on the progress of his various scripts.
Now he can arrive at the hyperloop terminal during the appropriate work time slot in Earth’s perpetual night. After which he simply walks up to his computer, flips a few switches, glances quickly at the display for verification, and goes to drink some nice, hydroponically grown, coffee. Just like the rest of us.
I’ve said over and over again that Apple’s MagSafe port is the greatest advancement in laptop tech in the last 15 years. Those charger connectors break, though, so how do you fix it? With Lego, of course (Google translatrix). Use a light-colored 1×4 brick so the LED will shine through.
Want to learn Git commands? Here’s a great game that does just that. It’s a really well-designed game/tutorial that walks you through basic Git commands.
Lets say you’re just slightly paranoid about the Bad Guys™ getting into your computer with 0-days and roller blades. You’d like to connect this computer to the Internet, but you don’t want to leave it connected all the time. The solution? A timer for an Ethernet switch. It’s actually a better solution than doing the same thing with scripts: there’s a real, physical interface, and if the Bad Guys™ get in when you are connected, they could just enable the network adapter anyway. An extremely niche use case, but that’s 99% of the security hacks we see.
The DaVinci 3D printer is an okay printer if you’re cool with the Gilette model. The filament cartridges are chipped, and the software is proprietary. These problems have been solved, and now you can use a standard RepRap heated bed and glass with the DaVinci. At this point, people are buying the DaVinci just to tear it apart.