Operating System - HP-UX
1833875 Members
2364 Online
110063 Solutions
New Discussion

Re: ksh bug, possibly exploitable?

 
SOLVED
Go to solution
A. Daniel King_1
Super Advisor

ksh bug, possibly exploitable?

I've got an unusual bug, and perhaps someone here can explain it. It has to do with executing commands unintentionally, so I thought I'd start with it from a security perspective.

Double-quote, back-tic, double-quote.

(or is that back-tick?)

We tracked it down this far. The original command was quite complex, but the problem can be reduced and replicated with:

$"`"
ksh: : Execute permission denied.
ksh: : Execute permission denied.

This is pretty toothless as it is, but the way we found this is that it was actually executing a potentially devastating shutdown script. Plus, it is not expected behavior from ksh. I cannot seem to reproduce the execution of a named program, though I know the command executed was in the PATH explicitly like "export PATH=$PATH:$SYSTEMDIR/bin"

It is not unusual that a command would be in the path like this, but consider that bin was a *script* and not a directory. It was probably placed in the bin location by mistake with a "cp $SOURCEFILE $SYSTEMDIR/bin" - the directory was removed some time ago, but the path entry was not removed.

I'm on HP-UX 11.0, v2200.

$what `which ksh`
/usr/bin/ksh:
$Revision: 82.10.1.38 $
Version 11/16/88
PATCH_11_00: arith.o blok.o ctype.o defs.o edit.o echo.o expand.o fault.o io.o string.o stak.o word.o emacs.o vi.o hpux_rel.o args.o builtin.o cmd.o main.o msg.o print.o xec.o name.o macro.o error.o service.o test.o jobs.o history.o 00/11/12

Any insight would be appreciated.
Command-Line Junkie
5 REPLIES 5
Scott Van Kalken
Esteemed Contributor

Re: ksh bug, possibly exploitable?

this works under any shell.

I first noticed this a few years ago on 10.20.

Never actually got around to finding out why though.

It slipped my mind, thanks for reminding me :)
A. Daniel King_1
Super Advisor

Re: ksh bug, possibly exploitable?

It does work under ksh and sh, but not csh nor bash.
Command-Line Junkie
Steve Bonds
Trusted Contributor
Solution

Re: ksh bug, possibly exploitable?

Someone got rooted, eh? :-( That's never a fun cleanup.

I noticed that the same behavior happens without the "$", i.e.:

$ ksh
$ "`"
ksh: : cannot execute
ksh: : cannot execute

I would get a copy of "tusc" (http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x3d9fee3e323bd5118fef0090279cd0f9,00.html) and check out the system call trace.

It looks like ksh is trying to execve() everything in the path. So a clever way of hiding a command might be to include it in the PATH (instead of a directory) and then run that wierd "`" command.

For example:

$ cat > /tmp/testme.sh
#!/bin/sh
echo $0 executed
^D
$ chmod 700 /tmp/testme.sh
$ export PATH=$PATH:/tmp/testme.sh
$ "`"
ksh: /tmp/testme.sh/ executed: not found
[note the strange buffering that I saw with the split "ksh: not found" result]

This might be exploitable if you can change a privileged users' PATH and get them to run that "`" command.

-- Steve
Steve Bonds
Trusted Contributor

Re: ksh bug, possibly exploitable?

Followup:

Try it with just:

$ ""

Same thing happens. Maybe this should go into "stupid shell tricks". ;-)

-- Steve
A. Daniel King_1
Super Advisor

Re: ksh bug, possibly exploitable?

$""

is not the same.

However, "`" does give the double error on Solaris Bourne shell (sh), as well. Go figure.

It would be a stupid shell trick, except that it has caused some serious headaches.
Command-Line Junkie