Hi,
Short answer: the default shell in your VM was deleted by a command you typed; the best thing to do is throw away your current VM instance, and start a new one.
Longer answer:
The reason you're seeing those errors is due to a failed, prior command that isn't shown in your screenshots. The output you've shown occurs when /bin/sh has been deleted or replaced with a "broken" symbolic link (that is, a symbolic link where the target file does not exist).
What happened was this: at some point, you tried to run sudo apt-get install -y zsh, and it failed for some reason (perhaps there were intermittent network connectivity problems, perhaps you mis-typed the command, or perhaps some other problem occurred – I can't tell). apt-get would've then displayed a failure message indicating that zsh didn't install correctly. Now, once a command that alters the system (e.g. by installing or removing a package, or altering a kernel parameter) fails, there's no real point carrying on with a lab until that command does succeed (i.e., in this case, by successfully installing zsh) – the best thing to do is usually to show a lab facilitator the original failing command, and get their assistance solving that initial problem. Any attempt to keep typing commands from the lab sheet isn't going to work, because they all assume that the previous commands completed correctly. Instead, typing more commands will just put the system into a more and more broken state (and probably make it harder for a facilitator to diagnose what's gone wrong).
So. After apt-get install failed, you then tried running the command sudo ln -sf /bin/zsh /bin/sh. But since zsh wasn't installed, there was no such file as /bin/zsh, and trying to create a link from /bin/sh to /bin/zsh would've create a link with no valid target: a broken link. (The ln command doesn't report a failure, in this case – it assumes the user knows best, and that if the user wants to create a broken link, then that's what the command should do. There are occasionally good reasons to create a broken link: e.g. because you're constructing a directory tree that, although it may be broken on your current filesystem, will be correct when copied over to some remote system you're using.)
Now, at this point, the VM would be largely unusable, since many accounts and commands on Ubuntu use "/bin/sh" as their default shell, and it no longer existed – all that remained at /bin/sh was the broken link created by the ln command. Attempting to run almost any complex command on the system would result in unusual errors, and that's what apt-get install and sh --version were showing.
Given all this, the best thing to do is to just discard the current VM instance and create another. (This is the great advantage of VMs – no matter what you do to them, it's cheap to just throw them away and start again.) You can do that by running (on your host machine, in the directory where your Vagrantfile is located) "vagrant destroy --force" to get rid of the current VM instance, and then "vagrant up --provider=virtualbox" to create a new one. Then, start the lab again from the beginning. I'd suggest doing it at an actual face-to-face lab, with a lab facilitator present. Unless they are very busy with students doing the current lab, they will be quite happy to help you with labs from previous weeks. (Just make it clear which lab you're working on, when you ask questions, and give them some time to look up that lab and refresh their memory of it.) If things go wrong, the facilitators have access to your VM and can investigate to find the root cause of any error, obtain more information about what commands you've already typed, and suggest alternatives. But without access to the laptop and VM, it's much more difficult for staff to diagnose problems (unless the problem is a very common one). In this case, I happened to recognize that the output you were seeing was from a system with a broken /bin/sh.
I hope that helps. In addition to attending a face-to-face lab, you might want to take a look at the worksheet solutions for some hints. It can be a challenging lab to complete, as crafting a successful exploit requires a good knowledge of systems programming and executable debugging – so if, in the end, you're not able to successfully exploit the "stack" program, you needn't be too worried about that. As long as you've acquired a better understanding of how buffer overflow attacks work, and how they can be defended against, then that's the main thing.
Cheers,
Arran
ANONYMOUS wrote:
Hi everyone :)
I'm currently having some issues while attempting Lab 5. Every time I try to install zsh, I encounter a whole lot of errors which I have attached as an image below. Then when I attempt to switch from dash to zsh and run 'sh --version', it returns an error saying 'Command 'sh' not found'. I have tried the method on the labsheet as well as trying to install zsh directly into the /bin directory but nothing is working...
Has anyone else ran into this issue and been able to fix it?
Thanks :)
