Red Hat Bugzilla – Bug 17179
security problem with mgetty
Last modified: 2008-05-01 11:37:58 EDT
Some mgetty filters are vulnerable to an attack when sender ID (usually fax numbe, but may be set to any string) has special symbols (like line feed inside). This way an arbitrary command may be executed. This is just few cases: grep '\$2' /usr/share/doc/mgetty-1.1.21/samples/* /usr/share/doc/mgetty-1.1.21/samples/coverpg.pbm: MEMO=$2 /usr/share/doc/mgetty-1.1.21/samples/coverpg.pbm: Fax: $2 /usr/share/doc/mgetty-1.1.21/samples/coverpg.ps: MEMO=$2 and others. The files like /usr/share/doc/mgetty-1.1.21/samples/new_fax.lj:SENDER="$2" /usr/share/doc/mgetty-1.1.21/samples/new_fax.mail:SENDER="$2" have $2 escaped as "$2" so these files are OK. Those which do not have argument escaped are vulnerable. similar problems may exist with other mgetty scripts.
Non-Problem. When assigning variables with blanks in them, NO QUOTES ARE NEEDED. $ a="a b c d" $ echo $a a b c d $ b=$a $ echo $b a b c d -> no problem here, even though $a contains whitespace. (Besides, the bug report mixes wildly different types of scripts - new_fax and coverpg are used in different surroundings. If a user calls coverpg with broken environment variables, and it executes arbitrary programs with his access rights - so what, he can execute them anyway)
White spaces are OK, but line feed (as I mentioned in the report) and some other symbols are not example: ---- file x a="`echo -e \"A\nB\"`"; if [ $a == "x" ]; then echo Y else echo N fi ------ sh x x: [: too many arguments N if you replace if [ $a == "x" ]; then to if [ "$a" == "x" ]; then everything is fine sh x N This type of behavior exactly specified in bash manual