why I like shared libraries -- no longer a popular position
<https://arstechnica.com/security/2023/09/incomplete-disclosures-by-apple-and-google-create-huge-blindspot-for-0-day-hunters/> A bug was found (painfully -- a zero day) in Apple's Safari and (separately) in Google's Chrome. This is a pretty serious bug -- it was used to spy on an opposition politician in Egypt. It is the same bug, and this was not reported. It turns out that the bug is in libwebp. "WebP codec is a library to encode and decode images in WebP format." libwebp is used in a lot of programs. On my Fedora 38 system, it is a shared library so it can be fixed in one update. Except where the library is copied (for example, statically linked, or used in a container of some sort). Electron is one thing that requires copies and the article lists a lot of applications built on Electron What a mess. What a mistake.
A bug was found (painfully -- a zero day) in Apple's Safari and (separately) in Google's Chrome. This is a pretty serious bug -- it was used to spy on an opposition politician in Egypt.
It is the same bug, and this was not reported.
It turns out that the bug is in libwebp. "WebP codec is a library to encode and decode images in WebP format."
libwebp is used in a lot of programs. On my Fedora 38 system, it is a shared library so it can be fixed in one update. Except where the library is copied (for example, statically linked, or used in a container of some sort).
Electron is one thing that requires copies and the article lists a lot of applications built on Electron
What a mess. What a mistake.
By shared libraries you dont mean libsomething.so, right? You mean everybody in the world using code they got from Somebody. Im just a little worried these days about the new .avif format. ImageMagick handles it in the Debian12 distribution, but it hasnt made it to the current Raspberry Pi OS. A libavif exists, but seems to be controversial and hard to find. Everybodys choice of fallback seems to be libheif. libheif depends on libde265. libde265 is said to have no dependencies, but wouldnt (IIRC) install without finding something involving SSL2. Finally, ImageMagick was built, but libheif wont actually do anything without a separate codec, which it can obtain from libaom. The libaom from a Google git site throws up fatal compile errors. So there I am. So the question arose in my mind What the heck IS this stuff? Since its 3AM and my mind is freewheeling I ponder If I were a well-funded system attacker, dont new image file formats look like a fine way to get everybody to install brand new kind-of-obscure library code (libaom.so on Debian12 is 5 megabytes) without asking embarrassing questions?
| From: mwilson--- via talk <talk@gtalug.org> | By ?shared libraries? you don?t mean libsomething.so, right? You mean | everybody in the world using code they got from ?Somebody?. [What are the question marks that appear where other punctuation is expected? Did your mail get badly transcoded at some step?] I mean the former. The latter is scary, as you point out. This is called a "supply chaing attack" these days. We need a better way of pushing back at problems with suppliers. Simply choosing not to adopt is good, but it would be better if you could signal to others your concerns. Shared critiquing. But even for critiquing there is a "free riders" problem. In the worst case, everyone thinks everyone else is doing the work and nobody does it. | Since it?s 3AM and my mind is freewheeling I ponder ?If I were a | well-funded system attacker, don?t new image file formats look like a fine | way to get everybody to install brand new kind-of-obscure library code | (libaom.so on Debian12 is 5 megabytes) without asking embarrassing | questions?? Quite right. A big concern. I hide my head in the sand and assume Red Hat vets the code it distributes. The fact is that it is a very hard problem to vet a small amount of code, let alone a whole distro. The linux kernel requires that code contributors be registered. I think that contibutions must be cryptographically signed, but I'm not sure. This helps but isn't air-tight. I don't see that static linking would help with this problem.
The linux kernel requires that code contributors be registered. I think that contibutions must be cryptographically signed, but I'm not sure. This helps but isn't air-tight.
This is news to me. No, there is no registration to work on the kernel. There us no single authority who you could register with. I believe i know what your misunderstanding is. after the 2012 breach, Linus prefers your tags be signed (i recall there are still a few straggler maintainers out there). This doesn’t affect the average contributor because they don’t send pull requests to Linus. Now because we wanted signed tags and key distribution is a fun problem, one needed to get their keys signed. The protocol was - I know this person and have verified their identity, so i will sign their key. One of the things we did was check each others government issued ids. Of course we are no experts in spotting fake ids so that is a risk factor considered. But for most part we signed each others keys and “verified” their identity and I think you misremembered it as registering. Dhaval
I don't see that static linking would help with this problem. --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
[What are the question marks that appear where other punctuation is expected? Did your mail get badly transcoded at some step?]
Transcoded must be the answer. I composed the message in LibreOffice Writer then copied the text and pasted it into the SquirrelMail reply screen from vex.net. The characters shown as ? started out as single and double quotation marks. Hmm.
On Sat, Sep 23, 2023 at 02:27:27PM -0400, mwilson--- via talk wrote:
Transcoded must be the answer. I composed the message in LibreOffice Writer then copied the text and pasted it into the SquirrelMail reply screen from vex.net. The characters shown as ? started out as single and double quotation marks. Hmm.
They ended up as backslash and a 3 digit number as if they were in some non standard character set (certainly not utf8 or ascii) with non standard escaping too. Email header claims it is utf8 but clearly something was not. -- Len Sorensen
People discovered that there was an NP-complete problem with competing versions of library functions, but instead of addressing it, they kluged around it with static linking, snaps and flatpacks. And ended up with a different problem, as Hugh noted. When faced with a NP-complete problem, one constructs your system so as to not have it. Don't hack up workarounds that add new problems. I pitched that to the Go community back in 2018, https://leaflessca.wordpress.com/2018/09/03/avoiding-an-np-complete-problem-... but they didn't hear it. --dave On 9/23/23 00:18, D. Hugh Redelmeier via talk wrote:
A bug was found (painfully -- a zero day) in Apple's Safari and (separately) in Google's Chrome. This is a pretty serious bug -- it was used to spy on an opposition politician in Egypt.
It is the same bug, and this was not reported.
It turns out that the bug is in libwebp. "WebP codec is a library to encode and decode images in WebP format."
libwebp is used in a lot of programs. On my Fedora 38 system, it is a shared library so it can be fixed in one update. Except where the library is copied (for example, statically linked, or used in a container of some sort).
Electron is one thing that requires copies and the article lists a lot of applications built on Electron
What a mess. What a mistake. --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
| From: David Collier-Brown via talk <talk@gtalug.org> In this case, a simple bug needs to be fixed. No interface change. The number of packages to update is the number with copies of this buggy code. Copies count, references (shred libraries) are free. Not as easy when interface changes (not additions) are desired or required. | People discovered that there was an NP-complete problem with competing | versions of library functions, but instead of addressing it, they kluged | around it with static linking, snaps and flatpacks. And ended up with a | different problem, as Hugh noted. I guess that I've been spoiled by C's maturity. The core libraries tend to mutate slowly and the Committee has as a base that revisions should not break programs (but they may break implementations). (I think that they failed badly in this when the negated the promise of int max_t. They refused to break ABIs so they broke programs. Better to have eliminated intmax_t (a noisy change) than break it (a silent change).) Languages like Rust and Go have libraries that have evolved and must evolve relatively quickly. Even the core libraries. In Linux, we see how major versions of GTK have stranded a variety of programs. The switch from X11 to Wayland has also been difficult. As time goes on, more of our work is adjusting to change rather than building change. We don't write programs, we assemble them. Then we have to shepherd the assembly through time. A different skill set, one that I haven't developed well. So: anything that makes this easier to do safely would be good. Avoiding a problem (not just putting it off) is great.
On 9/25/23 10:19, D. Hugh Redelmeier via talk wrote:
| From: David Collier-Brown via talk <talk@gtalug.org>
In this case, a simple bug needs to be fixed. No interface change. The number of packages to update is the number with copies of this buggy code. Copies count, references (shred libraries) are free.
The workaround for the hard problem was to use static linking, which makes distributing bug-fixes painfully difficult. That was one of the major motivations for shared libraries in the first place.
I guess that I've been spoiled by C's maturity. The core libraries tend to mutate slowly and the Committee has as a base that revisions should not break programs (but they may break implementations).
At Sun, we committed a 5-person team under a founder (David J. Brown) to beating immature changes into the ground. It was too dangerous to leave to a volunteer community, although numerous volunteer efforts helped us greatly. --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dave.collier-brown@indexexchange.com | -- Mark Twain CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.
Many years ago, I used Gentoo Linux as my primary O/S. I often wonder if I should try it again. It's a source based, rolling release distribution. Packages are compiled locally and usually dynamically linked to shared libraries. If a package isn't compatible with the latest release of a given library, it can be linked to an earlier version. The problem I had with Gentoo was that a fair amount of work was required to maintain the system, both by the user and with the time needed for compiles (especially if a change triggered the need to recompile a majority of the packages). If something broke, either during compiling or when running, it could sometimes be frustrating hunting down the fix or waiting for someone to solve the problem. Having not used it for some time, I'm not sure if things have gotten better in this respect. It can also take some effort deciding and fiddling with how you want to tailor it to your liking. However, I found it was quite a nice system to use when things were working properly. https://www.gentoo.org/ -- Scott
| Date: Sat, 23 Sep 2023 00:18:03 -0400 (EDT) | Subject: [GTALUG] why I like shared libraries -- no longer a popular position I posted earlier about two CVEs for one bug -- one for Safari and one for Chrome. I noted that the bug was in a library and, with static linking, in a lot of other programs. Well, a new, more comprehensive CVE has been released, two weeks late. <https://arstechnica.com/security/2023/09/google-quietly-corrects-previously-submitted-disclosure-for-critical-webp-0-day/> Since it is a "0-day" (i.e. already exploited in the real world), it is urgent that you update. Again. But we don't know when new versions of each affected program will be released.
| From: D. Hugh Redelmeier via talk <talk@gtalug.org> | It turns out that the bug is in libwebp. "WebP codec is a library to | encode and decode images in WebP format." | | libwebp is used in a lot of programs. On my Fedora 38 system, it is a | shared library so it can be fixed in one update. Except where the library | is copied (for example, statically linked, or used in a container of some | sort). Still more reverberation: copies exist in several Python projects. This paper appears to report on rather hard work to discover problems with projects in PyPI. <https://sethmlarson.dev/security-developer-in-residence-weekly-report-16> Perhaps analogous work is needed in many repositories. Of course libwebp might not be the only dangerous library.
participants (7)
-
D. Hugh Redelmeier -
Dave Collier-Brown -
David Collier-Brown -
Dhaval Giani -
Lennart Sorensen -
mwilson＠Vex.Net -
Scott Allen