check_request() bypass in archive plugin

[r0xen]

As explained in my last comment on #6229 (which I'm going to quote):

in archive.php:135 "_uids" it's taken via POST so it seems that you cannot exploit this since you'll end with check_request() checking for a token. But it's not like this. In archive.php:156 there's a call to rcmail::get_uids() which get "_uids" again BUT with INPUT_GPC. So after line 156 our _uids passed from GET it's injected. This by passes check_request: cause a request to ?_task=mail&_mbox=INBOX&_action=plugin.move2archive&_uid=exploit it's considered a post, with empty $_POST. Which means that in versions previous to the archive.php:move_messages() first check for ajax requests this it's exploitable by just tricking the victim with clicking and/or a simple html page. Posterior version may be more difficult to exploit due to same origin policy.

I tested this on roundcube 1.2.0 and a simple ?_task=mail&_mbox=INBOX&_action=plugin.move2archive&_uid=255%20BODY[HEADER]%0d%0aA0006%20CREATE%20%22hacked5%22%0d%0aA0007%20UID%20FETCH%20255 works flawless.
On more recent versions like 1.3.4-5 SOP kick-in but if it's somehow respected or bypassed then the same exploit works (will return a File not Found template, nonetheless code'll be executed).

PS: I'd like to publish an advisory on packetstorm about the whole thing, are you going to push out 1.3.6 anytime soon? It's okay for you if I go public prior to 1.3.6?

[carnil]

CVE-2018-9846 was assigned for this issue.

[StudioMaX]

Hello, guys. Could you comment on the current status of this issue? Are there any known cases of usages of this vulnerability? The thing is that a few days ago a lot of servers was hacked with the Vesta control panel, and several hosting providers said that the current working directory of virus was /usr/share/roundcubemail or /var/lib/roundcube. Details of this attack here: https://forum.vestacp.com/viewtopic.php?f=10&t=16556

[r0xen]

honestly I don't think they are related @StudioMaX

[alecpl]

I also think this is another issue. Fixed.

[dol]

Any reason this landed only in 1.3 and not 1.2? What's the state of the 1.2 branch? Does it still get security updates?

[thomascube]

@dol The reason is: we're understaffed but an update will follow soon. See http://lists.roundcube.net/pipermail/users/2018-April/011935.html

[dol]

@thomascube Thank you for pointing this out. No problem. We will wait. Thank you for the work.