This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] libio: Free backup area when it not required (BZ#22415)



On 14/12/2017 13:45, Florian Weimer wrote:
> On 12/14/2017 04:36 PM, Adhemerval Zanella wrote:
>>
>>
>> On 14/12/2017 09:57, Florian Weimer wrote:
>>> On 11/29/2017 02:39 PM, Adhemerval Zanella wrote:
>>>> Some libio operations fail to correctly free the backup area (created
>>>> by_IO_{w}default_pbackfail on unget{w}c) resulting in either invalid
>>>> buffer free operations or memory leaks.
>>>>
>>>> For instance, on the example provided by BZ#22415 a following
>>>> fputc after a fseek to rewind the stream issues an invalid free on
>>>> the buffer.
>>>
>>> Do we have to treat this as a security bug?  I don't think so, but I'd still like a second opinion.
>>>
>>> Thanks,
>>> Florian
>>
>> I am not well versed in exploit crafting, so how do we usually handle
>> invalid free on user provided buffers?
> 
> I'm not sure we have had many of those, so that we have a portfolio of bugs to look at for guidance.
> 
> Do you think it is likely that the conditions to trigger this bug would only hold for one set of input data, and not for another?  So that the invalid free only happens some of the time, and could be triggered by crafted input data?  Obviously, this depends a lot on how these functions are used, but it looks not very likely to me that there are applications out there which have this kind of input dependency here.

The bug is triggered independent of data, you need to basically
use a non-default buffer with setvbuf, trigger the auxiliary
buffer with ungetc and fseek after (so any operation following
will see dangling pointers). 

Using codesearch.debian.net, it looks like there is at least
529 packages that have calls to both setvbuf and ungetc (I am
considering fseek a common operation).  So it reasonable to
assume it indeed might happen in the wild.  The good think is
in my tests (and on bug reports) the invalid free is detected
by glibc and aborted (so I am not sure how undefined it is).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]