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.
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?
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.
net-im any news on this one?
To much email, and i missed the comment about real VS effective user. I'll be taking care of this tonight (i hope).
Gustavo any news on this one?
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.
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.
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
net-im / gustavoz : please bump jabberd with your new init.d...
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.
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...
Stable on hppa
Stable on SPARC.
Then we are done, thx everyone
