Bug 91478 – net-im/jabberd 1.4 relies on the setuid bit to drop privileges

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Andrew J. Korty 2005-05-04 12:58:16 UTC]

Making jabberd setuid jabber doesn't fully drop privileges.  The process will still run with root's group privileges, plus its real UID will still be zero, which means it can change its effective UID back to 0 with seteuid(getuid()).

Reproducible: Always
Steps to Reproduce:
1. emerge jabberd
2. ls -l /usr/sbin/jabberd
3.

Actual Results:  
-rwsr-xr-x  1 jabber jabber 150796 Nov 12 16:32 /usr/sbin/jabberd*


Expected Results:  
Don't set the setuid bit on jabberd.  Instead, use start-stop-daemon --chuid
jabber:jabber in /etc/init.d/jabber and the init scripts for all the transports.

[Comment 1 Gustavo Felisberto (RETIRED) 2005-05-04 15:23:40 UTC]

ps aux
cut some lines
jabber   28521  0.2  3.1  11428  8172 ?        S    May02   9:42 jabberd -B -c /etc/jabber/multiple.xml
jabber   14449  0.0  0.7   4232  1812 ?        S    May02   0:00 jabberd -B -c /etc/jabber/multiple.xml

If what you say is true then the user on the first colums should be root right?

[Comment 2 Andrew J. Korty 2005-05-07 09:36:18 UTC]

The command "ps aux" shows you the effective user, which is "jabber".  My point is that the real UID doesn't change.  Try the following command instead, which is the same as "ps aux" but displays the real user instead of the effective user:

ps axo ruser,pid,%cpu,%mem,vsz,rss,tty,stat,start,time,command

Also, see what I wrote about group privileges.

[Comment 3 Sune Kloppenborg Jeppesen (RETIRED) 2005-05-09 23:13:10 UTC]

net-im any news on this one?

[Comment 4 Gustavo Felisberto (RETIRED) 2005-05-10 12:44:18 UTC]

To much email, and i missed the comment about real VS effective user. I'll be taking care of this tonight (i hope).

[Comment 5 Sune Kloppenborg Jeppesen (RETIRED) 2005-05-11 07:25:05 UTC]

Gustavo any news on this one?

[Comment 6 Gustavo Felisberto (RETIRED) 2005-05-11 15:13:13 UTC]

This is really boring. Because start stop daemon works very baddly with jabberd 1.4 . The server will start but it will fork, have a new pid and the father will die. So start-stop-daemon will fail to kill the process. If i try to use the internal jabber way to store the pid in a file it will fail to start the jabberd.

I'll be attaching the new init.d script, maybe someone will come up with a new idea.

[Comment 7 Gustavo Felisberto (RETIRED) 2005-05-11 15:29:59 UTC]

Created attachment 58697 [details]
jabber.init.d

Well please try this, i'll try to use a similar system to the transports. This
is really an ugly hack. Good thing jabberd is much more clean and that the
newer transports also behave better.

[Comment 8 Thierry Carrez (RETIRED) 2005-05-13 02:20:51 UTC]

Note; this is not a vulnerability to me, it's just damage-control prevention stuff. If there is remote exec of code in jabber it can escalate to root. But there is no such thing yet, so this should be fixed but does not result in GLSA.

Setting to Default config

[Comment 9 Thierry Carrez (RETIRED) 2005-05-21 10:18:24 UTC]

net-im / gustavoz : please bump jabberd with your new init.d...

[Comment 10 Gustavo Felisberto (RETIRED) 2005-05-21 15:21:33 UTC]

koon: Gustavo Felisberto != gustavoz :) Gustavo Felisberto == humpback :)

jabberd-1.4.3-r5 is in portage and it is x86, all other arches need to follow.

[Comment 11 Thierry Carrez (RETIRED) 2005-05-22 02:00:24 UTC]

Gustavo: yes, I realized my mistake shortly after posting, but thought it wasn't
needing spamming the zillions of mailboxes that watch security@go :)

Many thx, calling remaining arches (sparc, hppa) to test and stabilize...

[Comment 12 René Nussbaumer (RETIRED) 2005-05-22 08:08:50 UTC]

Stable on hppa

[Comment 13 Jason Wever (RETIRED) 2005-05-23 18:21:00 UTC]

Stable on SPARC.

[Comment 14 Thierry Carrez (RETIRED) 2005-05-24 02:10:19 UTC]

Then we are done, thx everyone