| |||||||||||||
Wheeler: Insecure open source software libraries?Wheeler: Insecure open source software libraries?Posted Apr 10, 2012 10:17 UTC (Tue) by khim (subscriber, #9252)In reply to: Wheeler: Insecure open source software libraries? by HenrikH Parent article: Wheeler: Insecure open source software libraries?
And that is the main problem with bundling, if you bundle the library then you also have to maintain it or your application might all of the sudden become a security threat due to a problem in a bundled library. And it'll not be a problem because of problems in your own code… why, exactly? If you actively maintain your program then it's not a big deal to upgrade libraries, too. If you don't maintain it then it's either not a problem (for example the application is not supposed to work with potentially hostile data - compilers, for example: if your code comes from hostile source the you have larger problems then bugs in the compiler) or it's a problem even if libraries are not bundled with it (because sooner or later bug will be found in the program itself).
(Log in to post comments)
Wheeler: Insecure open source software libraries? Posted Apr 11, 2012 23:03 UTC (Wed) by HenrikH (guest, #31152) [Link]
>And it'll not be a problem because of problems in your own code… why, exactly?
Because I might receive data that is not dangerous to me but to the library and since the library call of course runs using my privileges it can be used to attack my application even though I have no bugs what so ever.
Just as an example, let's say that I can receive compressed data. Too me the data looks ok (has a valid length and a valid uncompressed length) but when feed to Z-lib it contains some sequence in the compressed stream that creates a buffer overflow in Z-lib, the attacker now has successfully attacked my application without there being a bug in my application.
But this scenario shouldn't a news for you so I sense that you ask/mean about something else?
Wheeler: Insecure open source software libraries? Posted Apr 12, 2012 6:39 UTC (Thu) by khim (subscriber, #9252) [Link] But this scenario shouldn't a news for you so I sense that you ask/mean about something else?Yup. I mean: sure, you can create a program which just checks the length of a data, then puts in a library and throws away the result. But usually program is processing the result somehow. And this processing often ends up being buggy. If someone maintains the program and fixes the bugs in it then it's not hard to pick new version of library when/if it's released, if noone maintains it then it's a security risk with or without shared libraries.
Wheeler: Insecure open source software libraries? Posted Apr 12, 2012 16:22 UTC (Thu) by HenrikH (guest, #31152) [Link]
So the application must contain bugs so that your idea that libraries must be bundled has no problems ;). And not having to focus on when various distributions finds faults in underlying libraries is far from not maintaining your application.
Wheeler: Insecure open source software libraries? Posted Apr 12, 2012 16:45 UTC (Thu) by khim (subscriber, #9252) [Link] So the application must contain bugs so that your idea that libraries must be bundled has no problems ;) Of course libraries bundling is a problem! But it's not “100% bullet-proof solution” vs “insecure solution”, but “pretty insecure solution” vs “slightly more secure solution”. And not having to focus on when various distributions finds faults in underlying libraries is far from not maintaining your application. Instead you need to focus on the cases when various distributions upgrade libraries and break your application insatead. Even GLibC update may break your application (see mamcpy saga again) - and these people are quite serious about backward compatibility. Hardly a progress. And if you'll recall that backward-compatibility and security are often at odds (just a recent example)… no, I don't believe the war on bundled libraries is good allocation of resources.
Wheeler: Insecure open source software libraries? Posted Apr 14, 2012 1:22 UTC (Sat) by HenrikH (guest, #31152) [Link]
>Instead you need to focus on the cases when various distributions upgrade libraries and break your application insatead. Even GLibC update may break your application (see mamcpy saga again) - and these people are quite serious about backward compatibility. Hardly a progress.
Well knock on wood but that has actually never happened to me yet, i.e backports to distribution libraries introducing bugs in my application. However if I got then perhaps I would have a different attitude towards it, that just comes naturally.
But the memcpy() is just silly, I have always used memcpy() in a way that the libc change would have introduced no problem, that's why there is a memmove(). The fault there lies entirely on Adobe.
|
|||||||||||||