Bug 989670 - (CVE-2013-1436) CVE-2013-1436 XMonad.Hooks.DynamicLog remote command injection flaw
CVE-2013-1436 XMonad.Hooks.DynamicLog remote command injection flaw
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 989671 989673
  Show dependency treegraph
Reported: 2013-07-29 13:26 EDT by Vincent Danen
Modified: 2013-08-08 17:24 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-08 17:24:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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

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:

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

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 13:28:25 EDT
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 03:46:37 EDT
This issue is CVE-2013-1436 and not CVE-2013-1435.
Comment 3 Vincent Danen 2013-07-30 12:08:54 EDT
Oops, it is indeed.  Sorry about that.
Comment 4 Fedora Update System 2013-08-05 20:24:51 EDT
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-05 20:25:43 EDT
ghc-xmonad-contrib-0.11.2-1.fc19, ghc-X11-, 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.