Ben Fowler blogs about the issues related to running IRC as root. Google searches for (irc client exploit) and (irc client “buffer overflow”) give a number of interesting web pages. Many of the exploits require the user to perform an action that’s slightly unusual, but why take a chance?
The advice to not run as root while generally sensible (run everything with minimum privileges as much as possible) is IMHO not very useful in recent times (and probably was never very useful). Generally when a user is worried about system compromise they are not worried about attackers having direct hardware access, the ability to corrupt system files, etc. They are worried that the attacker might read their email and access other personal files.
Therefore the instruction should be “don’t run IRC as root or as any account that has access to data which is important to you“. It’s not difficult to start an X-term that runs “exec su – ircuser irc” or “ssh -t ircuser@localhost irc“. Note that the -t option is required for ssh to make it allocate a pty even when receiving a command to run. Note also that in the case of su you need the exec option so that if the irc client is compromised and tries to perform a ioctl(0, TIOCSTI… based attack then it won’t succeed.
In any of these methods make sure that X access is not granted. Until we get Security Enhanced X working in a viable manner any process that can display an X window on your screen can own you totally. There are of course relatively safe ways of doing X, I have previously documented how to configure the Xephyr X server (replacement for Xnest) to allow a process with a different security context to safely display a graphical window on your desktop.
Generally I recommend not using a graphical X client on an untrusted network (IE anything other than an Intranet IRC server). I prefer to do my IRC in an account that’s not even on a machine that I care about and have it run screen so I can disconnect and re-connect from anywhere in the world.
When I first got SE Linux in Debian to be useful (when I could boot and run all programs without problem) I logged on to some IRC channels related to Debian with the security context of root:user_r:user_t. I admit that my actions in this regard could possibly be described as trolling, but I wanted to demonstrate what SE Linux can do. Unfortunately of the many people who told me off for logging in to IRC as root, none of them wanted to hear an explanation of why user_r is safe in this regard. I expect that most of them were running their IRC client in the same Unix account that was used for their email etc (and probably most of them had GPG keys accessible from such an account).
Sigh, it’s so easy to run IRC as a different user – in fact it’s probably the easiest of all network client programs to run in such a manner. There’s no reason not to.