- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: ksh bug, possibly exploitable?
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-25-2002 07:34 AM
04-25-2002 07:34 AM
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-25-2002 02:37 PM
04-25-2002 02:37 PM
Re: ksh bug, possibly exploitable?
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 :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-25-2002 02:43 PM
04-25-2002 02:43 PM
Re: ksh bug, possibly exploitable?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-25-2002 02:52 PM
04-25-2002 02:52 PM
SolutionI 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-25-2002 02:56 PM
04-25-2002 02:56 PM
Re: ksh bug, possibly exploitable?
Try it with just:
$ ""
Same thing happens. Maybe this should go into "stupid shell tricks". ;-)
-- Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-25-2002 03:10 PM
04-25-2002 03:10 PM
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.