Bug 989670 (CVE-2013-1436) - CVE-2013-1436 XMonad.Hooks.DynamicLog remote command injection flaw
Summary: CVE-2013-1436 XMonad.Hooks.DynamicLog remote command injection flaw
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2013-1436
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 989671 989673
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-29 17:26 UTC by Vincent Danen
Modified: 2019-09-29 13:06 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-08 21:24:32 UTC
Embargoed:


Attachments (Terms of Use)

Description Vincent Danen 2013-07-29 17:26:45 UTC
It was reported [1] that XMonad's contributed DynamicLog module was vulnerable to a remote command injection flaw.  From the report:

Background
==========
DynamicLog module feeds information to others programs about what's
happening on xmonad window manager. Such programs generally are status bars
as xmobar or dzen2. These programs features the ability of receiving
formatted input from stdin, and that's the way used by xmonad to
communicate information such as workspace status, current layout and window
title. So far, so good.

Both bars uses some meta-language to format their input. For example,
xmobar will make the following text clickable.

  <action=xclock>Click to clock</action>

Vulnerability & exploit
=======================
As we know, web browsers usually set the window title to the current tab. A
malicious user, then, can craft a special title in order to inject commands
in the current bar. In xmobar this will be something like this:

<html>
        <head>
                <title>&lt;action=xclock&gt;An innocent title&lt;/action&gt;</title>
        </head>
        <body>
                <h1>Good bye, cruel world</h1>
        </body>
</html>

So, if the user accidentally (or incidentally) clicks on the xmobar window
title, the command will be executed. In dzen2 this is also possible,
although I haven't tried to execute code. A (harmless) proof of concept is
attached for both bars. The proof for dzen2 just changes the background
color of the bar.

This has been corrected in upstream version 0.11.2 and a patch is available [3].

[1] http://www.openwall.com/lists/oss-security/2013/07/26/5
[2] http://hackage.haskell.org/packages/archive/xmonad-contrib/0.11.2/
[3] http://handra.rampa.sk/dawb/patch?repoPURL=http%3A%2F%2Fcode.haskell.org%2FXMonadContrib&repoPHash=20130708144813-1499c-0c3e284d3523c0694b9423714081761813bc1e89

Comment 1 Vincent Danen 2013-07-29 17:28:25 UTC
Created ghc-xmonad-contrib tracking bugs for this issue:

Affects: fedora-all [bug 989671]
Affects: epel-6 [bug 989673]

Comment 2 Henri Salo 2013-07-30 07:46:37 UTC
This issue is CVE-2013-1436 and not CVE-2013-1435.

Comment 3 Vincent Danen 2013-07-30 16:08:54 UTC
Oops, it is indeed.  Sorry about that.

Comment 4 Fedora Update System 2013-08-06 00:24:51 UTC
ghc-xmonad-contrib-0.11-1.1.fc18, bluetile-0.6-13.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 5 Fedora Update System 2013-08-06 00:25:43 UTC
ghc-xmonad-contrib-0.11.2-1.fc19, ghc-X11-1.6.1.1-1.fc19, xmonad-0.11-4.fc19, ghc-X11-xft-0.3.1-10.fc19, bluetile-0.6-18.fc19, xmobar-0.18-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.