Re: CVE-2024-28085: Escape sequence injection in util-linux wall

                							

                <!--X-Body-Begin-->
<!--X-User-Header-->

oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->

By Date

By Thread

</form>

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Re: CVE-2024-28085: Escape sequence injection in util-linux wall

<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->

From: Solar Designer &lt;solar () openwall com&gt;

Date: Thu, 28 Mar 2024 00:29:35 +0100

<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->

<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
Hi,

CC's added for upstream and reporter of the original issue, neither of
whom appears subscribed.

On Wed, Mar 27, 2024 at 07:00:02PM -0400, Demi Marie Obenour wrote:
On Wed, Mar 27, 2024 at 10:30:41PM +0100, Jakub Wilk wrote:
While looking through upstream git for a fix for this??, I stumbled upon
another write(1)/wall(1) control character injection vulnerability,
introduced last year in util-linux v2.39.

The offending commits are:

* https://github.com/util-linux/util-linux/commit/8a7b8456d1dc0e7c
  ("write: correctly handle wide characters")
* https://github.com/util-linux/util-linux/commit/aa13246a1bf1be9e
  ("wall: use fputs_careful()")

The added comment says:

The locale of the recipient is nominally unknown,
but it's a solid bet that the encoding is compatible with the author's.

Alas the bet is not that solid when writer's locale encoding is controlled
by an attacker.

We can exploit this against terminal emulators that recognize C1 control
characters, such as Linux VTs or screen(1):

   $ printf '\302\23331mMOO\302\2330m\n' | LC_ALL=kk_KZ wall

I don't see any good way to fix this on the util-linux's side. It should be
fixed on the terminal emulators' side by disabling C1 support.

?? https://github.com/util-linux/util-linux/commit/404b0781f52f7c04
  ("wall: fix escape sequence Injection [CVE-2024-28085]")

Would enforcing UTF-8 validity (regardless of user locale) be a
solution?

Not a complete solution.  I'm currently not aware of a safe way to allow
multi-byte characters coming from concurrent writers, see:

https://www.openwall.com/lists/oss-security/2015/09/20/1

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

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->

<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->

By Date

By Thread

Current thread:

CVE-2024-28085: Escape sequence injection in util-linux wall Skyler Ferrante (RIT Student) (Mar 27)

Re: CVE-2024-28085: Escape sequence injection in util-linux wall nightmare . yeah27 (Mar 27)

Re: CVE-2024-28085: Escape sequence injection in util-linux wall Jakub Wilk (Mar 27)

Re: CVE-2024-28085: Escape sequence injection in util-linux wall Demi Marie Obenour (Mar 27)

Re: CVE-2024-28085: Escape sequence injection in util-linux wall Solar Designer (Mar 27)

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->