rxvt buffer overflow?

[arrow]

Hi,
Trying to made a search on duckduckgo about what is the default terminal emulator on OpenBSD, I don't find this response, but other link [1] tell me about a buffer overflow vulnerability on rxvt on the past. Since the xterm is a old and over-coded piece of software and rxvt appear to be vulnerable (on old versions, I don't know currently), I made a search if are other good terminal emulator on the way. Don't find nothing, except the suckless SL [2]. The suckless is the same team of DWM window manager, and the SL seems to be a great software, write in C as most minimalist-as-possible.
Anyone use this? I will try to compile it later, but I will appreciate other opinions.
I'm not OpenBSD user (yet), but I'm doing some research about that project, because I want -current on a coreboot Thinkpad

Greetings.

[1] windowsdevcenter.com/pub/a /linux/2001/06/18/insecurities.html
[2]: st.suckless.org

[jggimi]

Hello, and welcome!

My primary terminal emulator in X is xterm(1). This application and its variants uxterm(1) and koi8rxterm(1) are part of the X.Org distribution. OpenBSD uses that distribution, but with some repackaging and its own Makefile overlays. The application is included in the xbase*.tgz fileset as a standard part of the X Windows System on the OS.

The xterm application is still actively maintained, and it has had a good deal of development since the mid 1990s. Its poor reputation may be somewhat dated, as /usr/xenocara/app/xterm/README says (highlight mine):

-- $XTermId: README,v 1.3 2007/05/24 19:49:19 tom Exp $
-- Below is the original README for xterm from 1991, for your amusement.
-- For a better overview, see http://invisible-island.net/xterm/ 
-------------------------------------------------------------------------------
            Abandon All Hope, Ye Who Enter Here


This is undoubtedly the most ugly program in the distribution.  It was one of
the first "serious" programs ported, and still has a lot of historical baggage.
Ideally, there would be a general tty widget and then vt102 and tek4014 
subwidgets so that they could be used in other programs.  We are trying to 
clean things up as we go, but there is still a lot of work to do.

If you are porting this to a machine that has problems with overlapping
bcopy's, watch out!

There are two documents on xterm: the man page, xterm.man, which describes
how to use it, and ctlseqs.ms, which describes the control sequences it
understands.

[arrow]

Originally Posted by arrow

Don't find nothing, except the suckless SL [2]

Just correcting myself, it is *ST* not SL.

Originally Posted by jggimi

Hello, and welcome!

Thanks jggimi! I hope to contribute positively to the forum.

Originally Posted by jggimi

OpenBSD uses that distribution, but with some repackaging and its own Makefile overlays.

Yes, it heard about xenocara, great. I's not the focus of this thread, but what exactly xenocara does? I read other day about put X over SSH [1], maybe xenocara does it.
If I substitute xterm with other terminal emulator, I "leak" the xenocara SSH [if it really do it]?
If it do, I can alert suckless team, since the most users are from *BSD (and put ST as daemon ).
Thanks.

[1]: lxer.com/module/forums/t/26874/

[ocicat]

Originally Posted by arrow

...but what exactly xenocara does?

Welcome!

Xenocara is simply the repackaging & tweaks made to X in order for it to run on OpenBSD. X is a set of daemons & libraries which establishes a messaging platform which X applications use to manipulate the display. As such, X applications act as clients connecting to the underlying X server.

...& the server does not need to exist on the same machine. Also implemented by MIT, X includes a protocol which can send messages over a network to a server running on a different machine. In this manner, X applications displaying on one machine may actually be running on another machine.

I read other day about put X over SSH [1], maybe xenocara does it.

X's networking protocol is traditionally large & susceptible to eavesdropping, so others can intercept it. A common trick done (for years) to secure X is to tunnel X traffic through an SSH session to take advantage of SSH's encryption. Xenocara handles this very well. Any other implementation of X running on other operating systems should be able to do the same thing too.

If I substitute xterm with other terminal emulator, I "leak" the xenocara SSH [if it really do it]?

xterm & any other terminal emulator are still simply X applications which can be tunneled within an SSH session just like any other X traffic.

[jggimi]

Arrow, your link to the LXer forum is a discussion of tunnelling X Windows in SSH -- very common and widely used -- but including a Microsoft Windows workstation. That complicates the subject a little, since Microsoft Windows has neither a native SSH client nor a native X Windows server, and third party software for both of those must be used.

An X application (called an "X Client") communicates with the software that drives display and input devices ("X Server") via networking protocols. Inside the same workstation, these protocols use local TCP sockets, and do not use any network interfaces. There is nothing to "leak" external to the platform.

The X Windows System security features are focused on authentication between X client applications and X servers. To the X Windows System, it does not matter if the clients and servers are on the same workstation, or using a network. Securing the network, or securing the workstation display memory, are outside of its concerns. The traffic between X client and X server is not encrypted, whether inside the same workstation or between systems using a network. SSH is commonly used when moving graphics between systems, to secure the network portion of the traffic.

Since you asked about terminal X client applications, when used for console traffic to remote systems, most commonly these are used only on local workstations, and only the terminal traffic (ASCII, UTF-8, etc.) is communicated remotely, and that can be done quite securely with a local SSH client connected to the remote system's SSH server. Moving character traffic is much faster than moving graphical traffic -- far fewer bytes are transmitted or received. All graphical traffic -- resizing and movement of windows, fonts, foreground/background colors, window management widgets, and in particular mouse pointer movement and display -- remain local to the displaying workstation and are not sent over any network, as both X client and X server are on the same platform.

There are other way to "move" graphical traffic over a network, and some work far more efficiently than X, or interoperate with both Unix-like systems and Microsoft Windows. One of those is VNC.

Originally Posted by ocicat

Also implemented by MIT...

I think you may mean, "As implemented," because the X Windows System was one of the first software products publicly released to the world through MIT's Project Athena, back in the mid 1980s.

[thirdm]

Originally Posted by arrow

Hi,
... other link [1] tell me about a buffer overflow vulnerability on rxvt on the past. Since the xterm is a old and over-coded piece of software and rxvt appear to be vulnerable (on old versions, I don't know currently), ...

That particular rxvt buffer overflow was from 2001, so we can assume it's fixed in more recent versions. The issue was one of a regular user running it being able to run code as the utmp user. rxvt was installed set group id with group of utmp, so that it could write a record into the utmp file at login. I just checked and xterm on openbsd is also set group id with utmp, no doubt for the same reason. So if there were a buffer overflow or similar exploit for xterm a user on your machine might use that to mess with your utmp file. I don't know if the vector goes farther than that. init manipulates utmp to delete entries, maybe if its utmp parsing were sensitive to weird input, that could be a way to root privilege?

Do you have other users running on your machine?

If not, a hypothetical xterm exploit would require a remote exploiter to somehow feed input to your local xterm. So how would it do that? You're saying you ssh to the openbsd machine, forwarding X? If the X server isn't trustworthy, e.g. if it has other xclients running on it you can't trust (and aren't contained by your using the X security extension or XACE -- I've had little luck running X security myself), the other clients could send key presses to your xterm. But if that's the case, I'd think someone grabbing utmp permissions would be the least of your problems. But then there's still the more mundane way of feeding xterm input, which is that programs you run on your terminal have output that somehow triggers a buffer overflow.

If you're concerned about this, you could change the permissions on xterm so it's not set to run as group id. There seems to be a -ut option to xterm to prevent it trying to write to utmp. You might need that to avoid a permissions error when you run a login xterm. What implications there are to not writing utmp entries I don't know. If you don't have other users on your machine, maybe you don't care about utmp.