Wheeler: Insecure open source software libraries? [LWN.net]

Wheeler: Insecure open source software libraries?

Posted Apr 8, 2012 16:14 UTC (Sun) by khim (subscriber, #9252) [Link]

I doubt it. There are no easy, simple, clean-cut answer to the question of library bundling.

From the distribution's POV library bundling is pure evil because it increases distribution's Q&A costs: if all programs use just one system library then you only need to update and check that one in a case where vulnerability is found, if programs use bundled libraries then they must be tested separately.

From the application developer POV library bundling is often preferable: it decreases application developer Q&A costs: there are no need to think about differences between versions of distributions (even if you support just one distro different versions of it pose the same problem). The downside is larger download binary but in today's world it's not a big problem.

Wheeler: Insecure open source software libraries?

Posted Apr 9, 2012 0:52 UTC (Mon) by HenrikH (guest, #31152) [Link]

Well each to their own I suppose but my own experiences as an applications developer is quite different. The Linux builds are the only packages that we never have to think about, when we release a new version we simply send it to the build server which builds debs and rpms for our selection of distributions and archs (currently 24 combinations) and then off it goes.

For other operating systems though like OsX and Windows we constantly have to be vigilant of security and/or bug fixes to any of the libraries that we use so that we can rebuild and redistribute the installer. Not to mention the problem that arises when users on these systems install software from other vendors who bundle the same libraries but with different versions (for example there is one company who have forked OpenSSL and sets the version to 9999.9999 in order to prevent other installers from overwriting it but since it's a fork from very long time ago it misses a lot of functions). Of course the solution is then to install all the bundled dll:s into our application directory but that is also ugly since the user now cannot take benefit of our updated libraries for the other software on his/her computer that uses the same library.

Wheeler: Insecure open source software libraries?

Posted Apr 9, 2012 7:18 UTC (Mon) by khim (subscriber, #9252) [Link]

TL;DR: we try to implement Linux-style policy and have a problem under MacOS/Windows, boo hoo, cry me a river.

Our experience is total opposite because we bundle everything with our packages and don't even try to install anything in system directory.

This is the only sane approach in a world without central packaging repository.

This works with Linux, too, but then we regularly hit the “missing library” or “wrong library version” issues on different distros.

ides

In a sense you are right: Linux way works poorly in MacOS/Windows while MacOS/Windows way is unreliable under Linux. But the fact of the matter is: most users and most developers use MacOS/Windows. And, frankly, 24 packages instead of one is just too much.

Of course the solution is then to install all the bundled dll:s into our application directory but that is also ugly since the user now cannot take benefit of our updated libraries for the other software on his/her computer that uses the same library.

And this is a problem, because… why exactly is it a problem? Why do you want to impose your unrequested “help” on other programs? I can understand the situation where upstream provides official installer (for example, MSVC runtume comes with appropriate installer), but why tempt fate with source-only libraries?

Wheeler: Insecure open source software libraries?

Posted Apr 9, 2012 9:33 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

> TL;DR: we try to implement Linux-style policy and have a problem under MacOS/Windows, boo hoo, cry me a river.

> Our experience is total opposite because we bundle everything with our packages and don't even try to install anything in system directory.

you make fun of people because (in your words), they try to take a linux approach on non-linux systems and it doesn't work well.

and then you are amazed that you don't get great sympathy because you try to take the windows approach on linux and it doesn't work as well as it would on windows.

stop a moment and thing about this.

Wheeler: Insecure open source software libraries?

Posted Apr 10, 2012 10:11 UTC (Tue) by khim (subscriber, #9252) [Link]

He who pays the piper calls the tune.

That's the general principle.

you make fun of people because (in your words), they try to take a linux approach on non-linux systems and it doesn't work well.

Sure. Most packages on MacOS/Windows are designed for MacOS/Windows and follow the principles of these systems. It's foolish to think that anyone will change MacOS/Windows to accommodate Linux expatriates.

and then you are amazed that you don't get great sympathy because you try to take the windows approach on linux and it doesn't work as well as it would on windows.

I'm not talking about sympathy. I'm talking about survival. Linux was, is and will be for foreseeable future a minuscule platform on desktop. It can not really dictate the rules. Linux desktop does not have a hardware base of it's own - it uses Windows leftovers (sometimes MacOS leftovers too, but this is rarity). This position is not sustainable. Long term one of the two things will happen:
1. Apple and Microsoft will change rules enough to kill Linux desktop completely.
or
2. Linux will manage to carve it's own niche with it's own hardware (it may be partially shared with MacOS/Windows, of course).

Till now this didn't happen because x86 server platform (where Linux is big player) and desktop platform (where it's hopeless loser) were one and the same. But nobody guarantees that this will be the case in the future: server and desktop diverge more and more as time goes on.

From what I'm seeing GNOME/KDE developers are trying to invent something to attract users and make #2 choice reality. But this approach does not really work because users need applications and most application developers don't know about Linux, don't want to know about Linux and most definitely don't want to learn “the Linux way”.

Wheeler: Insecure open source software libraries?

Posted Apr 10, 2012 17:19 UTC (Tue) by apoelstra (subscriber, #75205) [Link]

There will always be a requirement to support video hardware on servers, for local maintenance if nothing else (not to mention render farms, computational research, etc).

So even if "desktop hardware" diverges, it will always be possible for the Linux folks to buy server hardware and use it as a desktop.

Wheeler: Insecure open source software libraries?

Posted Apr 10, 2012 21:08 UTC (Tue) by khim (subscriber, #9252) [Link]

There will always be a requirement to support video hardware on servers, for local maintenance if nothing else

You can just use serial console or some cheap server video. Believe me: you don't want to use this thing to drive your 30" monitor.

(not to mention render farms, computational research, etc).

Well, sure. But these need entirely different drivers, they don't need consumer-style OpenGL at all.

I'm not saying hardware for desktops and servers will get full divorce tomorrow - but this is where development is going.

Wheeler: Insecure open source software libraries?

Posted Apr 9, 2012 13:59 UTC (Mon) by HenrikH (guest, #31152) [Link]

>Our experience is total opposite because we bundle everything with our packages and don't even try to install anything in system directory.

That is only one part of the problem, the main problem as I see it is that for our Linux customers we have to do nothing, the distribution managers takes care of making sure that all the libraries are upto date with security and bug-fixes while for our Windows customers we have to provide that support since no one else is doing it. 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 this is a problem, because… why exactly is it a problem? Why do you want to impose your unrequested “help” on other programs?

Because I care about our customers?

Wheeler: Insecure open source software libraries?

Posted Apr 10, 2012 10:17 UTC (Tue) by khim (subscriber, #9252) [Link]

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).

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.

Wheeler: Insecure open source software libraries?

Posted Apr 10, 2012 4:18 UTC (Tue) by michaeljt (subscriber, #39183) [Link]

dank wrote:
> Chrome is a best case scenario - it is an extremely well run project
which probably pays more attention to updating its bundled libraries
and pushing out the updates than 99.9% of all projects that bundle
libraries.

Something which I have been wondering about quite a bit recently would be a distribution-like infrastructure for building applications with bundled libraries, which automatically rebuilds when one of the bundled libraries needs to be updated and makes the new application binary containing the fixed bundled library available through whatever update channel it uses. You still need to redo your QA (in theory) every time one of the libraries gets a security update, but you get the security fixes and you greatly reduce your testing base. (Was that understandable?)