Hello, Just take a look at /usr/bin/fixproc Line 233 : # it must be "shell", so execute the shell script defined in database local ($tmpfile) = "/tmp/fix_$$"; &create_sh_script ($fix{$proc}, $tmpfile); # return code is number divided by 256 $error_code = (system "$tmpfile") / 256; ----------------------------------------- We see that the tmp file is created with $$ value and this script is execute by the perl system command The subfunction do only this : ------------------------------------- sub create_sh_script { local ($file) = pop (@_); local ($i) = pop (@_); printf (stderr "create_sh_script\n") if ($debug > 0); $! = $fixproc_error; open (file, ">"."$file") || die "$0: cannot open $file\n"; while ( $shell_lines[$i] ne $shell_end_marker ) { printf (file "%s", $shell_lines[$i]); $i++; } close (file); system "chmod +x $file"; return file; } ---------------------------------------- My knowledge in perl is not so good, but maybe a toctou or race condition could be exploited here, and permit to a basic user to run arbitrairie commands on the system ? Regards? Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: local ($tmpfile) = "/tmp/fix_$$"; is created without mktemp and chmod Expected Results: local ($tmpfile) = "/tmp/fix_$$"; should, maybe, created with mktemp and chmod
Auditors please confirm.
Looks like it could be a legitimate problem, but a call to mktemp from a perl script seems a bit excessive. Also, the same thing happens in do_check, so if one is to be fixed, the second should as well.
Taviso/Tigger/Solar please advise.
Confirmed, insecure tmp file handling, with a race condition for arbitrary command execution. File::Temp should be used instead of a pid based template.
Max will you relay this to upstream?
Or maybe the reporter (eromang) wants to report upstream to get the credits ?
Hello, OK i have contact upstream. http://sourceforge.net/tracker/index.php?func=detail&aid=1203376&group_id=12694&atid=112694 Regards.
Hello, Take a look on this : http://rpmfind.net/linux/RPM/suse/9.1/i386/suse/i586/net-snmp-5.1-80.i586.html * Tue Mar 16 2004 - ro@suse.de - use mktemp in fixproc (#36103) But net-snmp-5.2.1 still not corrected .... It seem that the upstream doesn't care about this bug. Regards.
5.2.1-r1 is in CVS. x86 stable. CC'd archs please stable.
stable on ppc64
Stable on ppc.
stable on amd64
stable on hppa
Sparcky SPARC and the Stable Bunch
Stable on alpha + ia64.
Ready for GLSA vote
Tool is administration-related and in path, I vote YES
I agree with koon, there should be a GLSA.
Hello, I agree also, if a GLSA is out, maybe upstream gonna correct the vulnerability :) Regards.
GLSA 200505-18 arm, mips please remember to mark stable to benifit from the GLSA.
Hello, Updates from upstream : https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1203376&group_id=12694 Also, published on : http://www.zataz.net/adviso/net-snmp-05182005.txt Regards.
Stable on mips.
