case 'd': sprintf(buffer, "<cparam '%c' (%f)>", self->tag, self->value.d); break; On one hand it seems crazy that stuff like this exists in a project as large as python but on the other C provides...
The buffer overflow happens due to not checking the length of th sprintf() function on line:
case 'd':
sprintf(buffer, "<cparam '%c' (%f)>",
self->tag, self->value.d);
break;
On one hand it seems crazy that stuff like this exists in a project as large as python but on the other C provides so many varieties of foot guns sometimes I’m surprised we’re not finding more.
It’s been a while since I’ve worked in C but is there ever a reason to use sprintf over snprintf? Isn’t this something that can be easily linted?
Confidentiality and Integrity set to None (C:N/I:N) because python packages in Red Hat products are compiled with FORTIFY_SOURCE, which provides runtime protection to this kind of memory errors and prevents the flaw from actually overwriting the buffer. Thus the impact is reduce to Availability only. Attack Complexity set to High (AC:H) because the flaw requires an application that uses ctypes with input not sanitized/checked that is used to construct a ctypes object.
On one hand it seems crazy that stuff like this exists in a project as large as python but on the other C provides so many varieties of foot guns sometimes I’m surprised we’re not finding more.
It’s been a while since I’ve worked in C but is there ever a reason to use sprintf over snprintf? Isn’t this something that can be easily linted?
It is, and gcc will even warn about it with
-Wformat-overflow.Interesting insight from the Red Hat link:
It warms my heart to no longer see Python 2.7 on patch notes.