Suppose that I have started a console application which finishes, then shell prompt brings up again. But how can I be sure that it's the real command prompt? What if, for example, the application is a "key logger" which starts a fake prompt when I try to exit?

So, how can I detect that I am actually in a pure shell (eg. bash) prompt?

  • 3
    The same worry, but expressed in terms of coming back to the true login program after apparently exiting the interactive login session, is what gave the world the concept of the secure attention sequence. – JdeBP Jan 13 '17 at 8:13

Technically, I will answer your question, ok. How you can ensure that you have come back to your shell? If you assume that the program is not malicious but you think it might run anoter shell, you can manually define a secret function with a secret content (that you will not export of course):

$ my_secret_func() { echo "Still alive"; }
$ ~/Downloaded/dubious_program
$ my_secret_func
Still alive

If dubious_program is malicious, it can easily trick you by passing on your input to the original shell and let it react. More generally, an unsafe executable has numerous ways to install a keylogger under your identity (and do many other malicious things), like installing itself in your ~/.bashrc for example. It could do so even if there were no visible effects — in fact, most malware tries not to have any immediate visible effect so as to minimize the risk of getting detected.

So, if your are not certain that what you execute is safe, either execute it with user nobody in a sandbox or don't execute it at all.

  • If dubious_program wishes, it can fake the execution of my_secret_func. It takes a bit more work if my_secret_func was defined interactively rather than in the user's shell startup file (in which case it'll happen automatically), but there's no guarantee. – Gilles 'SO- stop being evil' Jan 13 '17 at 18:58
  • This is an interactive shell. Do you mean by searching the history (for a prior definition) or dumping the tty content or searching /proc/.../mem? or something else? Of course there is no guarantee against such a directed attack. I just offer a solution for the standard type of malware that will just record what the user type and send it elsewhere. – xhienne Jan 13 '17 at 19:05
  • By ptracing its parent (if allowed, many systems prohibit this out of the box these days), by reading and reinjecting input, … Modifying the shell's output would be a bit more difficult: without ptrace, I think it would have to draw over the X11 window (possible in most scenarios). – Gilles 'SO- stop being evil' Jan 13 '17 at 19:09
  • @Gilles Quite interesting. That makes the OP's question rather pointless. But we all knew that, the best part of my answer was actually the last sentence. I was in the hope that downvoters would notice it. – xhienne Jan 13 '17 at 19:18
  • Your answer could be a good answer if it clearly stated that the my_secret_func thing was no help against a malicious program, instead of letting the reader believe that it's useful. – Gilles 'SO- stop being evil' Jan 13 '17 at 19:34

How to check whether you've returned to shell

Compare PID of shell before and after running a command (same PID means same shell):

$ echo $$
$ bash --posix
bash-4.3$ echo $$
bash-4.3$ exit
$ echo $$

In the demo above, you can see me starting an application, in this case another bash in POSIX mode. Upon returning , we verify that the PID of the shell we use is the same, thus we can assume this is the actual shell. That of course can be automated by adding $$ to your shell prompt:

$ PS1="[$$] $PS1 "
[6215] $

Variation on the theme can be done with checking a sha256sum ( or any other checksum , like md5) before and after. Sha-sums , if you don't know, are often used to check integrity of files, especially for downloads and iso images. In the demonstration below, we use /proc/<SHELL PID>/exe file, which is a symlink to actual binary (in this case , it would be my mksh shell). This way we can verify that the executable we're running is the same one.

$ sha256sum /proc/$$/exe
70a16895186ddfac12343e816f05783cf60092c0980fc20c2ae4bc53b48f28e6  /proc/12107/exe

$ bash --posix
bash-4.3$ sha256sum /proc/$$/exe
c2615a71ff5c004e51aef248103a2950c25715f5eb8130837695770e1d78ecfa  /proc/12434/exe
bash-4.3$ exit

$ sha256sum /proc/$$/exe
70a16895186ddfac12343e816f05783cf60092c0980fc20c2ae4bc53b48f28e6  /proc/12107/exe

Return to shell isn't guarantee of safety

As for key-loggers, they don't necessarily need to be inside shell. If you're using graphical terminal emulator, a key-logger can simply listen to the keystrokes being sent to any window, regardless of shell you use.

As far as shells themselves, it's possible to launch a process in background. For instance, shell scripts use ampersand like so command & to launch something in background. I'm not sure if a background process can still read keys, but the fact that shell exits isn't a guarantee that the app exited. In the small demo below, you can see a function being launched in background, the script seemingly exits, and yet the function still writes to out.txt every second.

$ cat launch_background_app.sh


    while true;
       date +%s > out.txt
       sleep 1

run_in_background &

$ ./launch_background_app.sh

$ cat out.txt

$ cat out.txt

$ cat out.txt

NOTE TO EDITORS: please don't remove the prompt from my example -it is there for demonstration purposes to show that shell PID remains the same.

P.S: security starts with installing a trusted application in the first place, so consider ensuring the integrity of the application before using it in the first place.

  • 4
    Overall I agree with your answer, but it would be fairly easy to make a malicious program that can overcome your checks. – Julie Pelletier Jan 13 '17 at 4:33
  • 1
    @JuliePelletier Absolutely true - there's always a way to overcome any security checks, and really there's no silver bullet solution for that. Especially, if user runs that untrusted application with sudo privilleges - it opens up whole lot of door to whole lot of malicious things that can be done, not just keyloggers, but subverting sha256sum binary, other programs, installing rootkits without user knowing , etc. Malicious users can't anticipate everything, so such checks might works on some, might not work on those who do anticipate it – Sergiy Kolodyazhnyy Jan 13 '17 at 4:40

A keylogger wouldn't try to fake a shell prompt, it would almost certainly leave behind a background process which monitors /dev/input or something similar (it will also try to hide itself in the process list). You're definitely looking at the problem the wrong way.

A common way of running untrusted binaries is to set up a virtual machine and run them there. Even that doesn't give you 100% safety, but it's often considered to be safe enough for practical use (of course, you won't run VMs with untrusted code on a production server or inside a protected network in a bank).

  • If I may suggest so as well, VM maybe shouldn't be connected to network as well. – Sergiy Kolodyazhnyy Jan 13 '17 at 11:29
 suspect-command; echo I am thinking of the number 43987

After the command exits echo will run. You should see the result on the line above the command prompt.

  • 3
    While this is good in theory, in practice this can easily fail, if suspect-command runs something in background. echo might still echo out the text you gave it, but again - that's not a guarantee of safety. But yes, we could say it's a simple approach to testing whether you returned back to original shell. – Sergiy Kolodyazhnyy Jan 13 '17 at 4:42
  • I think I answered the intent of the question... however Serg you could do something like run strace on the command and look at the strace log to be sure it exited without forking, etc. – William Deans Jan 13 '17 at 4:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.