| 2015-04-26 00:10:51 |
Reagan Sanders |
description |
libgetopt++1:
Installed: 0.0.2-p22-3ubuntu1
There is a use-after-free bug in OptionSet::doOption. For the Option::Optional and Option::Required switch cases, the following assignment is made:
optionValue = value.c_str();
In both cases, value's lifetime will end at the end of the block for that case, causing optionValue to contain a dangling pointer to the now potentially free'd buffer that value managed when it is later passed to theOption->Process at the end of the function.
Luckily, I do not see any obvious ways to exploit this bug. There does not appear to be any way for an attacker to control heap allocations between when the buffer is free'd, and when it will potentially be copied in StringOption::Process soon thereafter.
Even if an attacker could overwrite the free'd buffer with arbitrary data, given that it is only used to initialize another std::string, I suspect that the worst they could do would be to cause a segmentation fault.
There might also be the potential for a memory disclosure if the program reflects the option's value somehow, but given the likely use case of this library, that danger seems low as well. |
libgetopt++1:
Installed: 0.0.2-p22-3ubuntu1
There is a use-after-free bug in OptionSet::doOption. For the Option::Optional and Option::Required switch cases, the following assignment is made:
optionValue = value.c_str();
In both cases, value's lifetime will end at the end of the block for that case, causing optionValue to contain a dangling pointer to the now potentially free'd buffer that value managed. It is later passed to theOption->Process at the end of the function, which in turn may use it to initialize an std::string.
Luckily, I do not see any obvious ways to exploit this bug. There does not appear to be any way for an attacker to control heap allocations between when the buffer is free'd, and when it will potentially be copied in StringOption::Process.
Even if an attacker could overwrite the free'd buffer with arbitrary data, given that it is only used to initialize another std::string, I suspect that the worst they could do would be to cause a segmentation fault.
There might be the potential for a memory disclosure if the program reflects the option's value somehow, but given the likely use case of this library, that danger seems low as well. |
|
