The IPSEC livetest tool in Openswan 2.4.4 and earlier allows local
users to overwrite arbitrary files and execute arbitrary code via a
symlink attack on the (1) ipseclive.conn and (2)
ipsec.olts.remote.log temporary files.
Version 2.4.4 is quite ancient. Currently the oldest version available in our tree is 2.4.11.
I did not verify, but it is well possible that version is also affected. If you can, please help there.
I've removed this useless livetest script from versions 2.4.13-r1 and 2.6.18.
However, I doubt it is a valid security issue because:
a) cannot be triggered remotely
b) the host known as 192.168.0.1 by local machine must be controlled by the attacker (or at least its web service)
c) you need to trick the root user into running "ipsec livetest"
It is extremely unlikely that this will ever be exploited in the wild, but it's still a security issue (though a rather theoretical one).
Created attachment 168208 [details]
livetest script took from version 2.6.16
I'm not saying that the insecure temp file handling is a non-issue, I'm just saying this particular case is a non-issue. Let's analyse this script, shall we?
a) Since openswan daemon will not run this in any circumstance, this script must be executed by the user, through "ipsec livetest" command. However, the first thing that the script will do is identity checking through command "id -u"; if you are not root, it will do nothing.
b) Let's suppose you can trick user into running that command. wget will not override the output file, instead it will add a numeric suffix to the provided -O argument, in order to save the content into a new file.
c) What indeed is possible is that a local user could create a malicious /tmp /ipseclive.conn script and wait patiently for the superuser to run the livetest. But since this command is not documented anywhere (let alone that is pretty useless without the proper web application running on 192.168.0.1), I doubt it will ever do that.
This is a potentional root exploit:
cat /tmp/ipseclive.conn; echo id > /tmp/ipseclive.conn
Then, on an other terminal:
wget "https://bugs.gentoo.org/attachment.cgi?id=168208" -O livetest
Forgive the output, I do not have ipsec installed on this box:
[craig@nuw ~]$ sudo sh livetest
would do ikeping
livetest: line 32: ipsec: command not found
livetest: line 35: ipsec: command not found
uid=0(root) gid=0(root) Gruppen=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video),35(games),414(vmware)
livetest: line 42: ipsec: command not found
livetest: line 44: ipsec: command not found
cat waits for the input from wget to the fifo and after it received it, you immediately echo your command into the fifo which was empty again and viola, it gets executed, because the sh binary needs a few milliseconds to get loaded, it's a typical race condition.
You're right of course, it's very unlikely to be exploited, because you need a local account and must trick root into running the script, but in my opinion it's still a minor security issue.
linux-patch-openswan 2.4.12 allows local users to overwrite arbitrary
files via a symlink attack on (a) /tmp/snap##### and (b)
/tmp/nightly##### temporary files, related to the (1) maysnap and (2)
Let's handle that bug here, too.
Alin, was this fixed in 2.4.13-r1?
(In reply to comment #6)
I didn't said it cannot be exploited locally, I said it is highly unlikely (like one case in a billion, when the victim really doesn't know what he is doing) that someone will get bitten by this bug (see comment #5 point c).
(In reply to comment #7 to #9)
> Alin, was this fixed in 2.4.13-r1?
openswan-2.6.13-r1 doesn't install any file called mysnap or mytest.
Ready to vote, I vote NO.
Shouldn't this be B2 if it allows an attacker to trick someone into executing code?
D'oh. Of course.
I just read the topic, scrolled down fast, saw "symlink", the CVE, B3... forgot about and overread the code exec.
Good to see other people are watching...
Changing whiteboard accordingly and going to bed in order not create more fuckup on bugzilla (at least) this night... ;(
sorry, GLSA 200903-18