From: <no...@so...> - 2001-08-17 11:42:11
|
Patches item #452026, was opened at 2001-08-17 04:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=312694&aid=452026&group_id=12694 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcus Meissner (marcusmeissner) Assigned to: Nobody/Anonymous (nobody) Summary: security fixes for buffer overflows Initial Comment: Hi, this patch contains fixes for (potential) buffer overflows found in several parts of the ucd-snmp code. This was done during a routine security audit by Olaf Kirch <ok...@ca...> of Caldera Systems. Ciao, Marcus (mm...@ca...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=312694&aid=452026&group_id=12694 |
From: <no...@so...> - 2001-09-14 22:33:26
|
Patches item #452026, was opened at 2001-08-17 04:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=312694&aid=452026&group_id=12694 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcus Meissner (marcusmeissner) Assigned to: Nobody/Anonymous (nobody) Summary: security fixes for buffer overflows Initial Comment: Hi, this patch contains fixes for (potential) buffer overflows found in several parts of the ucd-snmp code. This was done during a routine security audit by Olaf Kirch <ok...@ca...> of Caldera Systems. Ciao, Marcus (mm...@ca...) ---------------------------------------------------------------------- >Comment By: Wes Hardaker (hardaker) Date: 2001-09-14 15:33 Message: Logged In: YES user_id=76242 Marcus, In your analysis did you happen to note which of the buffers you were looking at were actually problematic? I need to look at your patch in greater detail (it's quite long) but the majority of the places patched are not problematic because of the context in which the buffers are getting used. I'm hesitant to apply the patch in fear of it breaking functionality (IE, it's not heavily tested) and because it changes some API signatures. As I think we've mentioned to you before, we're in the process of rewritting a bunch of the APIs for the upcoming 5.0 release, where many of these issues have already been handled (and the rest will be). Therefore this patch will greatly conflict with that ongoing work (and though it's possibly to apply it to separate trees within the CVS tree, it makes merging a bit of a pain (if not impossible)). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=312694&aid=452026&group_id=12694 |
From: <no...@so...> - 2001-09-27 17:51:35
|
Patches item #452026, was opened at 2001-08-17 04:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=312694&aid=452026&group_id=12694 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcus Meissner (marcusmeissner) Assigned to: Nobody/Anonymous (nobody) Summary: security fixes for buffer overflows Initial Comment: Hi, this patch contains fixes for (potential) buffer overflows found in several parts of the ucd-snmp code. This was done during a routine security audit by Olaf Kirch <ok...@ca...> of Caldera Systems. Ciao, Marcus (mm...@ca...) ---------------------------------------------------------------------- Comment By: Olaf Kirch (okir) Date: 2001-09-27 01:17 Message: Logged In: YES user_id=230378 Wes, What I recall is that there were two or three potential overflows involving hostnames returned via gethostbyname; sometimes to 200-byte sized buffers. Note that older resolver libs would return hostnames of up to 1500 bytes; no restrictions on the character set. Recent resolver functions in glibc (coming straight from the BIND source) are much more anal about what the accept, but can still produce very long names under some circumstances. Overall, I feel that the current snmp code doesn't do a very good job defending against buffer overflows, which is why I created that patch, which is admittedly huge and intimidating :) As far as testing is concerned, our own test department has been banging on my patches, as well as a Caldera OEM, and there didn't appear to be any problems. Cheers Olaf ---------------------------------------------------------------------- Comment By: Wes Hardaker (hardaker) Date: 2001-09-14 15:33 Message: Logged In: YES user_id=76242 Marcus, In your analysis did you happen to note which of the buffers you were looking at were actually problematic? I need to look at your patch in greater detail (it's quite long) but the majority of the places patched are not problematic because of the context in which the buffers are getting used. I'm hesitant to apply the patch in fear of it breaking functionality (IE, it's not heavily tested) and because it changes some API signatures. As I think we've mentioned to you before, we're in the process of rewritting a bunch of the APIs for the upcoming 5.0 release, where many of these issues have already been handled (and the rest will be). Therefore this patch will greatly conflict with that ongoing work (and though it's possibly to apply it to separate trees within the CVS tree, it makes merging a bit of a pain (if not impossible)). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=312694&aid=452026&group_id=12694 |
From: <no...@so...> - 2001-10-02 00:03:05
|
Patches item #452026, was opened at 2001-08-17 04:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=312694&aid=452026&group_id=12694 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcus Meissner (marcusmeissner) Assigned to: Nobody/Anonymous (nobody) Summary: security fixes for buffer overflows Initial Comment: Hi, this patch contains fixes for (potential) buffer overflows found in several parts of the ucd-snmp code. This was done during a routine security audit by Olaf Kirch <ok...@ca...> of Caldera Systems. Ciao, Marcus (mm...@ca...) ---------------------------------------------------------------------- >Comment By: Wes Hardaker (hardaker) Date: 2001-10-01 17:03 Message: Logged In: YES user_id=76242 Ok, I think all of these types of problems have been fixed in the 4.2.2.pre3 release and beyond. If you have a second, we'd love it if you'd glance over it. Note that we didn't do it with your patch, as we had already started work in a similar direction ourselves (adding realloc support for generic buffers) and hence didn't want to apply yours directly due to conflicts with that. So, that work was back-ported by John to the 4.2.2 branch in the tree. Anyway, this unfortunately means you may not want to read through it all again as the changes are different than yours and equally as significant! ---------------------------------------------------------------------- Comment By: Olaf Kirch (okir) Date: 2001-09-27 01:17 Message: Logged In: YES user_id=230378 Wes, What I recall is that there were two or three potential overflows involving hostnames returned via gethostbyname; sometimes to 200-byte sized buffers. Note that older resolver libs would return hostnames of up to 1500 bytes; no restrictions on the character set. Recent resolver functions in glibc (coming straight from the BIND source) are much more anal about what the accept, but can still produce very long names under some circumstances. Overall, I feel that the current snmp code doesn't do a very good job defending against buffer overflows, which is why I created that patch, which is admittedly huge and intimidating :) As far as testing is concerned, our own test department has been banging on my patches, as well as a Caldera OEM, and there didn't appear to be any problems. Cheers Olaf ---------------------------------------------------------------------- Comment By: Wes Hardaker (hardaker) Date: 2001-09-14 15:33 Message: Logged In: YES user_id=76242 Marcus, In your analysis did you happen to note which of the buffers you were looking at were actually problematic? I need to look at your patch in greater detail (it's quite long) but the majority of the places patched are not problematic because of the context in which the buffers are getting used. I'm hesitant to apply the patch in fear of it breaking functionality (IE, it's not heavily tested) and because it changes some API signatures. As I think we've mentioned to you before, we're in the process of rewritting a bunch of the APIs for the upcoming 5.0 release, where many of these issues have already been handled (and the rest will be). Therefore this patch will greatly conflict with that ongoing work (and though it's possibly to apply it to separate trees within the CVS tree, it makes merging a bit of a pain (if not impossible)). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=312694&aid=452026&group_id=12694 |
From: <no...@so...> - 2002-03-21 15:34:20
|
Patches item #452026, was opened at 2001-08-17 04:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=312694&aid=452026&group_id=12694 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Marcus Meissner (marcusmeissner) Assigned to: Nobody/Anonymous (nobody) Summary: security fixes for buffer overflows Initial Comment: Hi, this patch contains fixes for (potential) buffer overflows found in several parts of the ucd-snmp code. This was done during a routine security audit by Olaf Kirch <ok...@ca...> of Caldera Systems. Ciao, Marcus (mm...@ca...) ---------------------------------------------------------------------- Comment By: Wes Hardaker (hardaker) Date: 2001-10-01 17:03 Message: Logged In: YES user_id=76242 Ok, I think all of these types of problems have been fixed in the 4.2.2.pre3 release and beyond. If you have a second, we'd love it if you'd glance over it. Note that we didn't do it with your patch, as we had already started work in a similar direction ourselves (adding realloc support for generic buffers) and hence didn't want to apply yours directly due to conflicts with that. So, that work was back-ported by John to the 4.2.2 branch in the tree. Anyway, this unfortunately means you may not want to read through it all again as the changes are different than yours and equally as significant! ---------------------------------------------------------------------- Comment By: Olaf Kirch (okir) Date: 2001-09-27 01:17 Message: Logged In: YES user_id=230378 Wes, What I recall is that there were two or three potential overflows involving hostnames returned via gethostbyname; sometimes to 200-byte sized buffers. Note that older resolver libs would return hostnames of up to 1500 bytes; no restrictions on the character set. Recent resolver functions in glibc (coming straight from the BIND source) are much more anal about what the accept, but can still produce very long names under some circumstances. Overall, I feel that the current snmp code doesn't do a very good job defending against buffer overflows, which is why I created that patch, which is admittedly huge and intimidating :) As far as testing is concerned, our own test department has been banging on my patches, as well as a Caldera OEM, and there didn't appear to be any problems. Cheers Olaf ---------------------------------------------------------------------- Comment By: Wes Hardaker (hardaker) Date: 2001-09-14 15:33 Message: Logged In: YES user_id=76242 Marcus, In your analysis did you happen to note which of the buffers you were looking at were actually problematic? I need to look at your patch in greater detail (it's quite long) but the majority of the places patched are not problematic because of the context in which the buffers are getting used. I'm hesitant to apply the patch in fear of it breaking functionality (IE, it's not heavily tested) and because it changes some API signatures. As I think we've mentioned to you before, we're in the process of rewritting a bunch of the APIs for the upcoming 5.0 release, where many of these issues have already been handled (and the rest will be). Therefore this patch will greatly conflict with that ongoing work (and though it's possibly to apply it to separate trees within the CVS tree, it makes merging a bit of a pain (if not impossible)). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=312694&aid=452026&group_id=12694 |