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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=morozwc1dkkj4uhls8sxfnx+ndlp67dgz4gzqgqlxz...@mail.gmail.com
