https://cxsecurity.com/issue/WLB-2017050013


http://www.cnnvd.org.cn/web/xxk/ldxqById.tag?CNNVD=CNNVD-201705-135

Rxvt是一个彩色VT102中断仿真程序，可以作为xterm的替代软件。 Rxvt 2.7.10版本中存在安全漏洞。攻击者可利用该漏洞造成拒绝服务（越边界读取）。

Hello,

A CVE for this in the process of being assigned, and I'll follow up on this
thread once one has been given.

There exists an integer overflow in rxvt. As the upstream project is dead,
there is no non-vulnerable version. Thus, I'd recommend distributions use
the attached patch. Do note that rxvt is different from rxvt-unicode (urxvt),
which is still maintained by an upstream and is not vulnerable to this bug.

Using the following escape code will segfault rxvt:

        $ printf '3[-2147483648L'

The crash occurs here in screen.c:

    for (; i--; j++) {
        r->screen.tlen[j] = 0;
        r->screen.text[j] = r->buf_text[i];
        r->screen.rend[j] = r->buf_rend[i];

We appear to be segfaulting on the read to r->buf_text[i], where i is
2147483647 -- 0x7fffffff. Slightly earlier in that function we have this
block:

    if (count < 0)
        count = -count;

Before this block is run, count is -2147483648 -- 0x80000000. After the block
is run, count should be 2147483648, right? Not so fast. It turns out that
there's no complement of -2147483648 within 32-bits, because the maximum
positive integer is 2147483647, one less. Probably if you read the C spec it
will tell you that this operation is undefined, but what's for certain is that
on my architecture, the integer remains negative -- -2147483648. We then
bypass the next few blocks, since count is negative, until we get to this
line:

        j = row2 - count + 1, i = count;

Thus, by the time we get to the crashing block, i has become -2147483648 - 1,
which is our crashing value of 2147483647, and so we segfault.

It comes from a call to rxvt_scroll_text from inside rxvt_scr_insdel_lines. Here
we have the following multiplication:

    rxvt_scroll_text(r, r->screen.cur.row, r->screen.bscroll, insdel * count,

In this case insdel is -1, for the INSERT operation, and count is our
-2147483648. Predictably, we still don't become positive. Backtracing a step
further reveals that this comes from a call inside of rxvt_process_csi_seq,
where the actual escape code is converted from a string.

The attached patch simply bounds the size of input values, so that they don't
overflow on multiplication or a few small additions and then a multiplication.

I've also attached a similar patch for rxvt-unicode. While it is not
vulnerable to this particular attack, the attached patch may be
"best practice". I've also sent this upstream and am awaiting their
response.

While this particular bug is in rxvt, I suspect that other terminal emulators,
such as rxvt-unicode, xterm, libvte, konsole, tmux, screen, mosh, etc, may
indeed suffer from similar types of bugs. Thus, research into this domain could
prove useful.

Jason

来源:MLIST

链接:http://www.openwall.com/lists/oss-security/2017/05/01/15

来源:MLIST

链接:http://www.openwall.com/lists/oss-security/2017/05/01/18