Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 28 Mar 2024 10:10:27 +0100
From: Karel Zak <>
To: Solar Designer <>
	"Skyler Ferrante (RIT Student)" <>
Subject: Re: CVE-2024-28085: Escape sequence injection in
 util-linux wall

On Thu, Mar 28, 2024 at 12:29:35AM +0100, Solar Designer wrote:
> > > 
> > > ??
> > >   ("wall: fix escape sequence Injection [CVE-2024-28085]")
> > 
> > Would enforcing UTF-8 validity (regardless of user locale) be a
> > solution?
> Not a complete solution. 

There is only one real solution: do not allow non-root users to write
to foreign file descriptors. Do not install wall(1) with suid. That's

For now, it is enabled by default in the upstream tree, but I will
disable it in the next releases and explicit --enable-* will be
required. We also need to add more information to the man pages.


I'm currently not aware of a safe way to allow
> multi-byte characters coming from concurrent writers, see:
> and the next message in that thread.
> In fact, even plain ASCII isn't entirely safe if it just happens to be
> injected into the middle of a control sequence that the target user's
> program was printing, thereby altering its effect.
> That said, perhaps write(1)/wall(1) just shouldn't allow bytes from both
> C0 and C1 ranges (except for TAB, LF, space) regardless of locale
> settings, at least when the programs are running SUID/SGID.  That is,
> unless the invoking user - which in this case is likely root - could
> have directly written to the target user's tty anyway.  In other words,
> mostly revert those offending commits.  Or just revert them completely.
> Alexander

 Karel Zak  <>

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.