Mailing List Archive

libclamunrar and several year-old critical vulnerability in unrar code
Hello,

a critical vulnerability in the unrar Code (version 5.5.3) has been
rediscovered (has already been noticed in Sophos-specific unrar code in
2012 but the fix has never made it upstream):

https://bugs.chromium.org/p/project-zero/issues/detail?id=1286&desc=6#maincol

checking the unrar code in libclamunrar, I found that exactly the same
vulnerability exists:

> [...]
> int op_type, cur_channel, byte_count, start_pos, pa, pb, pc;
> [...]
> case VMSF_DELTA:
> data_size = rarvm_data->R[4];
> channels = rarvm_data->R[0];
> src_pos = 0;
> border = data_size*2;
>
> SET_VALUE(FALSE, &rarvm_data->mem[VM_GLOBALMEMADDR+0x20],
> data_size);
> if ((unsigned int)data_size >= VM_GLOBALMEMADDR/2) {
> break;
> }
> for (cur_channel=0 ; cur_channel < channels ; cur_channel++) {
> unsigned char prev_byte = 0;
> for (dest_pos=data_size+cur_channel ; dest_pos<border ;
> dest_pos+=channels) {
> rarvm_data->mem[dest_pos] = (prev_byte -=
> rarvm_data->mem[src_pos++]);
> }
> }
> break;
> [...]
The test file given on the page linked above does not trigger the
problem with clamscan, but only due to the code in question not being
executed, because of other issues at other places. I was able to
reproduce the invalid memory write taking the following steps (against
tag clamav-0.99.2, corresponding to the latest stable release):

- increase the size of the memory region allocated for vmcode in
unrar.c::read_vm_code() and initialize it properly (inspired by the way
the current "upstream" implementation of unrar allocates memory)

--> without this "fix", the test file causes libclamunrar to read
from unitialized memory, resulting in a vmcode array that doesn't pass
the test in unrarvm.c:rarvm_prepare xor_sum (and thereby preventing the
vulnerable code to be executed)

--> this issue has been fixed by a more clean approach in the
current master branch by introducing bounds checking in getbits;
thereby, the correct vmcode array is created
(https://github.com/vrtadmin/clamav-devel/commit/7cdd2b551244d83add7d3f7062ea11475a51762a)
and the code advances past the xor_sum check.

- I (by somewhat by qualified guessing) commented
libclamunrar/unrar.c:894 (master) to make the unpack routine continue,
which otherwise fails after some iterations in unrar.c:110. Thereby, the
invalid memory access can be reproduced. If the cancellation of
processing before is a bug or a feature, I currently can not tell.

I do currently neither know enough about the RAR format nor about the
purpose of the used code, but as it seems there are a number of (quite
pointless?) read system calls with length=0 in rar_unp_read_buf, which
finally fails due to unpack_data->in_addr advancing beyond
unpack_data->read_top. To me, it seems that the code fails to continue
processing by chance more than by purpose. Be that as it may, the
vulnerability should be fixed in any case. I would not be surprised if a
slightly modified test file could cause the issue to surface with the
unmodified code.

Apart from that, are there any plans to use the current upstream version
of unrar? While this would have been counterproductive in the case at
hand, at least it could possibly help to reduce synchronization issues
in the future. The current version of libclamunrar seems to be a quite
messy piece of code and there been at least some improvements in the
"upstream" version.

Kind Regards,

Andreas

--
Mit freundlichem Gruß / Best regards,

Andreas Weigel
UTM Backend Developer

Securepoint GmbH
Salzstrasse 1
D-21335 Lüneburg

https://www.securepoint.de

Tel.: +49(0)413124010
Fax: +49(0)4131240118

Geschäftsführer: Lutz Hausmann, Claudia Hausmann
Amtsgericht Lüneburg HRB 1776
USt.-ID-Nr.: DE 188 528 597

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

http://www.clamav.net/contact.html#ml
Re: libclamunrar and several year-old critical vulnerability in unrar code [ In reply to ]
Yes. We are currently working on a fix to this issue.

--
Sent from my iPhone

> On Jun 23, 2017, at 05:19, Andreas Weigel <andreas.weigel@securepoint.de> wrote:
>
> Hello,
>
> a critical vulnerability in the unrar Code (version 5.5.3) has been rediscovered (has already been noticed in Sophos-specific unrar code in 2012 but the fix has never made it upstream):
>
> https://bugs.chromium.org/p/project-zero/issues/detail?id=1286&desc=6#maincol
>
> checking the unrar code in libclamunrar, I found that exactly the same vulnerability exists:
>
>> [...]
>> int op_type, cur_channel, byte_count, start_pos, pa, pb, pc;
>> [...]
>> case VMSF_DELTA:
>> data_size = rarvm_data->R[4];
>> channels = rarvm_data->R[0];
>> src_pos = 0;
>> border = data_size*2;
>>
>> SET_VALUE(FALSE, &rarvm_data->mem[VM_GLOBALMEMADDR+0x20], data_size);
>> if ((unsigned int)data_size >= VM_GLOBALMEMADDR/2) {
>> break;
>> }
>> for (cur_channel=0 ; cur_channel < channels ; cur_channel++) {
>> unsigned char prev_byte = 0;
>> for (dest_pos=data_size+cur_channel ; dest_pos<border ; dest_pos+=channels) {
>> rarvm_data->mem[dest_pos] = (prev_byte -= rarvm_data->mem[src_pos++]);
>> }
>> }
>> break;
>> [...]
> The test file given on the page linked above does not trigger the problem with clamscan, but only due to the code in question not being executed, because of other issues at other places. I was able to reproduce the invalid memory write taking the following steps (against tag clamav-0.99.2, corresponding to the latest stable release):
>
> - increase the size of the memory region allocated for vmcode in unrar.c::read_vm_code() and initialize it properly (inspired by the way the current "upstream" implementation of unrar allocates memory)
>
> --> without this "fix", the test file causes libclamunrar to read from unitialized memory, resulting in a vmcode array that doesn't pass the test in unrarvm.c:rarvm_prepare xor_sum (and thereby preventing the vulnerable code to be executed)
>
> --> this issue has been fixed by a more clean approach in the current master branch by introducing bounds checking in getbits; thereby, the correct vmcode array is created (https://github.com/vrtadmin/clamav-devel/commit/7cdd2b551244d83add7d3f7062ea11475a51762a) and the code advances past the xor_sum check.
>
> - I (by somewhat by qualified guessing) commented libclamunrar/unrar.c:894 (master) to make the unpack routine continue, which otherwise fails after some iterations in unrar.c:110. Thereby, the invalid memory access can be reproduced. If the cancellation of processing before is a bug or a feature, I currently can not tell.
>
> I do currently neither know enough about the RAR format nor about the purpose of the used code, but as it seems there are a number of (quite pointless?) read system calls with length=0 in rar_unp_read_buf, which finally fails due to unpack_data->in_addr advancing beyond unpack_data->read_top. To me, it seems that the code fails to continue processing by chance more than by purpose. Be that as it may, the vulnerability should be fixed in any case. I would not be surprised if a slightly modified test file could cause the issue to surface with the unmodified code.
>
> Apart from that, are there any plans to use the current upstream version of unrar? While this would have been counterproductive in the case at hand, at least it could possibly help to reduce synchronization issues in the future. The current version of libclamunrar seems to be a quite messy piece of code and there been at least some improvements in the "upstream" version.
>
> Kind Regards,
>
> Andreas
>
> --
> Mit freundlichem Gru? / Best regards,
>
> Andreas Weigel
> UTM Backend Developer
>
> Securepoint GmbH
> Salzstrasse 1
> D-21335 L?neburg
>
> https://www.securepoint.de
>
> Tel.: +49(0)413124010
> Fax: +49(0)4131240118
>
> Gesch?ftsf?hrer: Lutz Hausmann, Claudia Hausmann
> Amtsgericht L?neburg HRB 1776
> USt.-ID-Nr.: DE 188 528 597
>
> _______________________________________________
> http://lurker.clamav.net/list/clamav-devel.html
> Please submit your patches to our Bugzilla: http://bugs.clamav.net
>
> http://www.clamav.net/contact.html#ml
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

http://www.clamav.net/contact.html#ml