Bug#692065: RFS: mcrypt/2.6.8-1.3 [RC][NMU]
On Thu, Nov 1, 2012 at 7:54 PM, Jean-Michel Vourgère wrote:
>>> * CVE-2012-4527: stack-based buffer overflow by encryption / decryption of
>>> overly long file names (Closes: #690924)
>
>> I've reviewed this and it looks mostly good. However, can you explain
>> why you chose ERRWIDTH=PATH_MAX+1024 vs. the redhat patch WIDTH=80?
>
> I don't know exactly.
> It sounds reasonable:
> - We want to print one file name possibly 2 with program_name.
> - In a case of a file crafted to exploit this, it is likely than only one name
> with be very large. Having a large buffer will show the end of the message
> and one insane name.
> - tmperr is a static buffer. Having it to 3k should not bring any trouble.
> There is only one instance.
> - The buffer is only used in printf so that this is not an issue either.
If you think this is a better approach, please contribute to the
dialog on the redhat bug, and get them to adopt your solution.
> Fell free to put the buffer size back to 128, or use only the 80 first bytes like redhat.
> Or increase it more to 2*MPATH_MAX+sizeof(largestmessage).
> This will fix the CVE in all cases.
It's your nmu, so that isn't really my decision.
> The obvious fix should be changing all the err_crit like functions to use va_args.
> But I believe it is beyond scope.
Again, determining the "right" solution would be best to discuss on
the redhat bug or preferably with upstream.
Until those things happen, I am going to suggest that we as potential
sponsors wait for a "right" solution to work out.
Best wishes,
Mike
Reply to: