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.wei...@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

Reply via email to