Unix/Linux shells which use effective UID instead of real UID

Question

My question is build on top of the answer of the question about SUID exploitation:

SUID not used after exploit

The person (official answer) is stating that:

Many popular implementations of sh drop privileges when they start up: they reset their effective UID to their real UID. This includes bash, dash, mksh and BusyBox sh, so on Linux you won't see anything else.

So my question is which shells don't perform such critical security checks?

I tested it on my Ubuntu machine (18.04) and it seems that all shells are implementing such security checks:

ubuntu@ubuntu: cat /etc/shells
# /etc/shells: valid login shells
/bin/sh
/bin/bash
/bin/rbash
/bin/dash

If I run (make simplest possible check):

root@ubuntu: echo "secret" > root-file.txt
root@ubuntu: cp /bin/bash /tmp/foo && chmod u+s /tmp/foo
lowpriv@ubuntu: ./tmp/foo -c "cat root-file.txt"

I get for all shells (as expected):

cat: root-file.txt: Permission denied

So it works for all standard (shipped with Ubuntu) Ubuntu-shells.

Answer 1

At least fish, ksh93, yash and zsh are available in Ubuntu, but not installed by default, and don't drop privileges when they start. Perl and Python are installed by default and don't drop privileges.

This is not a “critical security check”. If an adversary can cause an interpreter to be setuid, they can also run code as that user. If they can inject code into a setuid program and they want to run a shell, they can upload their own interpreter that doesn't have a check, or leverage some non-shell interpreter such as perl, or run native code.

I think some shells have historically done this to prevent setuid scripts, which are a bad idea because it's very difficult to make a setuid shell script robust against all possible environment variables. They keep doing this today for backward compatibility, even though modern unices don't honor the setuid bit on scripts.