This is a scary one ... CVE-2024-3094

[golden_labels]

Trust is not trivial and neither knowing the person, nor credentials are foolproof either. I remind you of the University of Minnesota incident or Freenode takeover.

Yes, I'm on Arch, and xz did get affected. They let the 5.6.0 and 5.6.1 slip with this issue. It was quickly fixed though. So xz-5.6.0 is affected, xz-5.6.1-1 is affected, xz-5.6.1-2 is fixed. Check if you're concerned and if so, just update your system.

No worries:

Code: [Select]

[2024-03-29T08:10:22+0100] [ALPM] upgraded xz (5.6.1-1 -> 5.6.1-2)And a hint: compare the update time with when Phoronix announced the bug.

Arch recommends updating 5.6.1-2 and I strongly suggest doing the same. But that’s an advice. Advices are not trying to accurately describe reality.

If you want to, and until then not figure it out yourself, in a few days I will tell the details.⁽¹⁾ It’s not a secret, but I don’t want to make somebody not follow the recommendation or argue with it based on what I wrote. This would be very unfortunate.

⁽¹⁾ c8e7d38a7257c23d1b035f8012c265d87ab12479ddbde60761f1e4c221851271

[44kgk1lkf6u]

Thing is, this kind of event may trigger the requirement to share one's identity in full for contributing to any open-source software, at some point. Which is something I'm not sure I like either.

Why would verifying one's identity help at all?

[SiliconWizard]

Thing is, this kind of event may trigger the requirement to share one's identity in full for contributing to any open-source software, at some point. Which is something I'm not sure I like either.

Why would verifying one's identity help at all?

Again, not saying I like the idea either. For a number of reasons.
But the rationale would be making contributors of open-source software, especially software that is widely used, liable. Unfortunately, complete anonymity prevents any kind of liability. If a contributor, just like in this very story, injects something malicious and nobody even knows how to go after them, that can be considered a serious issue. Particularly if the consequences were severe. If the full identity of this guy was known, I doubt he would have pushed this malicious stuff.
So, that's just the idea. Not saying it's a solution, but I doubt it won't be raised at some point.

I find it fun that someone the nickname of which is just a code would be the one to ask this question, though. Probably just a coincidence.

[AndyBeez]

 

[Nominal Animal]

Thing is, this kind of event may trigger the requirement to share one's identity in full for contributing to any open-source software, at some point. Which is something I'm not sure I like either.

Why would verifying one's identity help at all?

When the real-world human behind the actions is contactable/trackable, the two main things are:

• Social pressure, lack of cover, lack of anonymity.
  Do not underestimate how much more difficult it is to pull this kind of thing off, especially more than once, when your identity is known to the target.
  It is easy to exploit people you do not know, but much harder to exploit people you do know.  Most people are not suited for police and intelligence undercover work, and those that are, usually need actual training to pull it off; and even then, some people get "turned" simply due to the close interaction.
   
• Legal action.
  While this kind of shenanigans are unlikely to lead to a court case, if the identity of the perpetrator is known, their international movements and even bank transfers will be monitored by Interpol and intelligence services, because this kind of thing is a security risk at the governmental level.

I do not know if "liability" is the correct term for this here –– it might; I do not know –– but the above two are the "realistic" effects in my opinion.

I slightly disagree with SiliconWizard in that I don't mind the requirement of revealing ones identity in full; I mind any kind of requirement of publishing contributors identities (in full, or in sufficient detail to be targeted by others who don't like your output, or would like to, uh, "entice" you to introduce some security hole or another).

That is, I do not see a problem having to reveal ones identity in full to a project maintainer or a small group of maintainers.  Because of their position in the project, they are already in a position of trust.  That is also sufficient to "trigger" my points above.

[SiliconWizard]

If you want to, and until then not figure it out yourself, in a few days I will tell the details.⁽¹⁾ It’s not a secret, but I don’t want to make somebody not follow the recommendation or argue with it based on what I wrote. This would be very unfortunate.

Yes, the situation is not all rosy as the issue is, actually, not really "fixed" as I got it. But at least the last package update should, for now, avoid running into it. That is, if xz doesn't contain yet other problems that haven't been detected yet. Who knows. I think they are currently analyzing all commits made by this guy.

xz has been criticized for a number of other reasons anyway, so maybe time to drop it altogether.

On Arch, it wasn't used by sshd, but xz can be used for compressing the kernel image, and it may even have been the default compression at some point. The last Arch install I did, xz was used for that, but I had switched to zstd, because it was much faster and I didn't care for the small difference in compression ratio for that.

But I'm guessing that using it for the kernel image could potentially cause a whole range of nasty issues too. Not sure yet.

[SiliconWizard]

A bit of history for the whole affair here: https://unicornriot.ninja/2024/xz-utils-software-backdoor-uncovered-in-years-long-hacking-plot/
Another one: https://boehs.org/node/everything-i-know-about-the-xz-backdoor

Yeah.

[radiolistener]

here is the page with description, it has the bash script at the end which checks if your system is vulnerable for this issue.

https://www.openwall.com/lists/oss-security/2024/03/29/4

And here is the page with update about this issue from Lasse Collin (original author of xz):

https://tukaani.org/xz-backdoor/

[mfro]

Really smells like an attack from a three letter organization.

Let alone the fact that the backdoor wasn't implemented in the main code but in the tarball packaging (boring stuff and probably not under close inspection of the most knowledgeable developers). Then the infiltration of the spy/saboteur over years - could be right from an espionage thriller.

The very same thing can/will happen (or happened already) at commercial vendors. The only difference: we'll probably never come to know.

[SiliconWizard]

Yes, just the way it was all prepared over a couple years, patiently, the guy gaining trust until he got more responsibilities, that's pretty nasty and is unlikely to come from just a lone wolf.

Now one lesson to learn is not to rely on pieces of software that are just maintained by one person for anything critical, that's just insane. Here it's malicious, but it could just as well have come from an unintentional security hole. (Reminds me a bit of the log4j debacle, in that sense.) It's like almost every Linux distro has been using xz without even knowing exactly what it did (the specs themselves are a mess), who was behind it, and whether it was actually a good idea to use it.

The xz format (not even its implementation) has been studied and is known to have severe flaws. Sure, you got better compression ratios with it that most other compression tools (although that's not always the case depending on the content), but was it worth using it blindly?

[golden_labels]

If only we gave control to some large company, they would provide us with security. Not some filthy amateurs not able to maintain their own projects. If that was Microsoft, such a situation would never happen. They would never let Jia Tan’s code slip into their flagship product. Neve… oh, oops!

Are you people sober? On one hand you believe this was done by a state actor. On the other you act as if that was a problem on Lasse Collin’s end. I just wait to see Diaz’s 2016 article, because suddenly everybody needs a rationalization for xz being the issue. Secondary victimization never dies. This is really getting disgusting. 🤦

[Nominal Animal]

It's like almost every Linux distro has been using xz without even knowing exactly what it did

You mean like CVE-2021-3560 (polkit privilege escalation), which was missed for only seven years, and exploitable trivially using a shell script?

Of course, the difference here is that because the affected projected was not part of the blessed SystemD, it is okay (and not hateful) to blame xz as a project.
(And that the xz one is a remote execution bug and CVE-2021-3560 is a privilege escalation one.)

If only we gave control to some large company, they would provide us with security. Not some filthy amateurs not able to maintain their own projects.

My three-letter agency can beat your three-letter agency, so there!  Besides, I need branding to validate my feelings of security, now that nationalism and preference for non-POC/non-DEI-based culture is universally condemned as colonialistic and evil.


I think Lasse Collin acted irresponsibly for not verifying the identity of the person they handed control of the project over to.  Everything else is the distributions' and software developers own damn fault, for not giving a shit about the stuff they rely on.

[hans]

Thing is, this kind of event may trigger the requirement to share one's identity in full for contributing to any open-source software, at some point. Which is something I'm not sure I like either.
So, I don't know how to tackle this other than by strict review processes, which are very time-consuming.

I think another key take away is that any discussion that becomes emotional can become a security hijack by design.
Things like: "Please hurry up, we need this fixed" or "doing things XYZ like you did is absolutely stupid" or "this project deserves more"
Ironically this would make some other key figures in OSS a major security hazard as well.

When it comes to review processes.. the use of binary blobs appears to be another puzzle piece: I've seen elsewhere people saying that blobs should never appear in [open source] code. But I disagree.. for compression libraries, its necessary to test malformed streams. You could generate or manipulate malformed streams, but such tests can quickly escalate into integration tests instead. It can become a real mess to manage..

Fortunately there are not that many repo's out there where binary blobs are a relative need, though, so that is hopefully a slight relief. I don't think this backdoor would have been possible for every repository. It is compounded by compression libraries being looked at with very few people.. If you don't have sound theoretical knowledge its unlikely you can contribute very much to them. I don't think its fair to then blame that every repo with only 2 maintainers is bad, because that's reality I'm afraid.

I don't think an ID will help much. It would probably also repel many genuine privacy focused developers. We can't say for sure if this was the work of a solo hacker, an underground group or a gov agency. In the latter, they also have spies and can probably arrange any ID they need. I don't think Jia Tan even exists. At best, asking for IDs would provide a false sense of security and perhaps an unnecessary hurdle. Besides.. many security/intel agency also had their own share of whistleblowers or moles..

[nctnico]

A good reminder that the human in the security chain is always the weakest link.  And that when you collaborate with someone on a widely-used project, make sure you know the actual human, including real-world traceability and contact when this kind of crap occurs.  A single e-mail address and connections via VPN is definitely not that.

True, but this case is also an example open source as a concept to develop software in a large scale collaboration works due to the many eyes looking at the software. For sure it is not the first time something like this happens on purpose or by mistake but it gets out in the open. And most importantly, it gets fixed.

How many planted security exploits are there in closed source software?

[mfro]

... True, but this case is also an example open source as a concept to develop software in a large scale collaboration works due to the many eyes looking at the software ...

Umm. In this specific case it appears it still was not enough eyes on the code.

I think the main culprit was that the attack was targeted against the source package (probably something no interested and skilled main developer really wants to spend too much time on, so even less eyes). A simple "fix" to that could be if distributions would build upon the released git checkout instead?

What I still don't get is how Andres Freund found the issue. He wrote he had seen unusual high cpu load from ssh connection attempts that failed during performance testing of a Postgres database. Did he really do tests using a testing OS version on a publicly accessible machine?

[madires]

Not much info about that.

Fom https://mastodon.social/@AndresFreundTec/112180406142695845:

I was doing some micro-benchmarking at the time, needed to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd, showing lots of cpu time in liblzma, with perf unable to attribute it to a symbol. Got suspicious. Recalled that I had seen an odd valgrind complaint in automated testing of postgres, a few weeks earlier, after  package updates.

From https://www.openwall.com/lists/oss-security/2024/03/29/4:

After observing a few odd symptoms around liblzma (part of the xz package) on
Debian sid installations over the last weeks (logins with ssh taking a lot of
CPU, valgrind errors) I figured out the answer:

The upstream xz repository and the xz tarballs have been backdoored.

[Bud]

This story does not pass a BS sniff test. Do you "state actor" theory proponents really think a state actor would leave such stupidly obvious indicators behind? 

[shapirus]

This story does not pass a BS sniff test. Do you "state actor" theory proponents really think a state actor would leave such stupidly obvious indicators behind? 

Easy.

[golden_labels]

This story does not pass a BS sniff test. Do you "state actor" theory proponents really think a state actor would leave such stupidly obvious indicators behind?

The question is apparently to proponents of the state actor explanation, so I’m not the one asked, but I’ll respond nonetheless.

Not sure what indicators you’re talking about, but whatever they left: yes, a state actor would leave “stupidly obvious indicators”  behind. I don’t know, how you imagine operations carried out by state agencies. But reality is not spy fiction and action movies.

[SiliconWizard]

Thing is, this kind of event may trigger the requirement to share one's identity in full for contributing to any open-source software, at some point. Which is something I'm not sure I like either.
So, I don't know how to tackle this other than by strict review processes, which are very time-consuming.

I think another key take away is that any discussion that becomes emotional can become a security hijack by design.
Things like: "Please hurry up, we need this fixed" or "doing things XYZ like you did is absolutely stupid" or "this project deserves more"

Yes, of course. Note that this one happens frequently in for-profit companies too. That's how engineers are pressured. Manipulated.

Ironically this would make some other key figures in OSS a major security hazard as well.

Probably.

When it comes to review processes.. the use of binary blobs appears to be another puzzle piece: I've seen elsewhere people saying that blobs should never appear in [open source] code. But I disagree.. for compression libraries, its necessary to test malformed streams. You could generate or manipulate malformed streams, but such tests can quickly escalate into integration tests instead. It can become a real mess to manage..

Binary blobs *purely for testing purposes* are "fine", the issue is with whatever code uses them. Binary blobs should be used *only* for testing known good outputs vs. actual outputs and the code for testing should be as simple and straightforward as possible. Period. Anything looking remotely "clever" for this should be banned. Also, the testing phase should be checked to have absolutely zero impact on the built artefacts themselves.

In this xz case, the testing code was so ridiculously convoluted that it should have triggered suspicion immediately, even if it wasn't malicious. The issue is that nobody looked at it until it was too late.

[Nominal Animal]

It is also a good reminder of how true security has to be baked in to the entire design, entire development chain, entire process; and not just added on top as an afterthought.

This particular vulnerability/exploit shows how dynamic linking mechanisms can be used via a library required by a library required by the actual target binary.  The ifunc mechanism allows this without using an interposing constructor function using the dl library; it was mostly used for obfuscation.  Renaming the target function and using a weakref alias would have raised eyebrows.

As an attack pattern, it means that every library is security sensitive when a binary executed with privileges is considered.

As it is not realistic to expect every single library to be fully vetted for security –– we do not have enough willing eyeballs for that –– the only viable approach is privilege separation.  That requires modularity, and when combined, directly leads to minimalism to limit the security sensitive surfaces, including library dependencies (direct and indirect).  Add the KISS principle as a reminder, and you get the Unix philosophy.

Which is why I so snarkily referenced CVE-2021-3560, which was a seven-year wide open privilege escalation flaw, resulting exactly from rejecting the points in the above paragraph.  Security is not a thing you can add, it is a fundamental approach to the entire task chain.

[shapirus]

...systemd esse delendam.

[Nominal Animal]

...systemd esse delendam.

For me, it is only an example of widespread use of an obvious security and single point failure risk (with a track record proving that), resulting from a deliberate rejection of privilege separation, modularity, and minimalism; and how good PR and social interaction and community management can convince otherwise smart people to acquiesce to stupid stuff.

(Consider the case where instead of an untraceable pseudonym, the changes to xz were made by a well-known, well-trusted developer.  There would be huge social pressure on their side, claiming inexcusable racist/ideological/personal accusations without any foundation.  That is what makes it so enticing for security actors to turn key developers.  In my opinion, the only workable solution is to trust no-one any more than you absolutely have to, and suspect everyone, even yourself; the key point in privilege separation.)

Another similar point is the entire security scheme used to implement interactive websites (including this one) under Apache or Nginx.  The idea of running scripts under the same user account that owns the scripts or the directories they lie in is exactly opposite to everything we know about multi-user security from the last fifty years or more.

None of these rants is new to anyone who has read my posts on similar subjects.  If only I had the charisma or reputation to convince anyone and make a difference... 

[shapirus]

Another similar point is the entire security scheme used to implement interactive websites (including this one) under Apache or Nginx.  The idea of running scripts under the same user account that owns the scripts or the directories they lie in is exactly opposite to everything we know about multi-user security from the last fifty years or more.

That's why, when I had to run WordPress in production, I implemented it in a way that: a) it does not have write access to the local file system whatsoever; b) there is no block storage volume or other file system mount point other than the container image's tree; c) the containers that it runs in are completely ephemeral.
No in-place plugin updates. No way to overwrite any PHP code on local drive. No way for wp admins (yes some stuff unfortunately requires to grant admin privileges to regular editors) to screw up anything on the local fs. Reproducible builds. Easy to make changes and roll back.

It made it, of course, somewhat of a pain in the ass to manage, at times, since a great number of WP plugin developers have horse shit in place of their brains (including big ones like Elementor -- and I do loosely guess that it can be said about most of plugins), which makes them assume that there is always a writable location under the WP root directory -- not only under wp-uploads/, but, sometimes, even other locations! But the long-term gains outweigh that.

That's an example of how it can sometimes be possible to mitigate the inherent security risks of poorly designed software.

[golden_labels]

I believe a week is enough. As promised, an explanation. The full shell-ed explanation at the bottom. A shorter explanation here:

Arch Linux never included the patch, which was pulling liblzma into OpenSSH, so “/usr/bin/sshd” on Arch was never touched by this vulnerability.
xz-5.6.1-1 was built from the affected tar with malicious build instructions, but these instructions — as far as it’s known — were not executed against Arch Linux. xz-5.6.1-2 and xz-5.6.1-3 are built directly from a repo tag, not including the malicious instructions.

The policy is to update to at least 5.6.1-2 and I will stand by that despite what I write below. Advisory statements and positive statements about factual state are, however, very different beasts.

5.6.1-1 and 5.6.1-2 actually produce the same liblzma, bit-to-bit identical regarding any executable path. There are two tiny differences in .note.gnu.build-id and .gnu_debuglink sections. Neither of which is meant to be executed and doesn’t even make sense as code.

5.6.1-3 is an unrelated rebuild, which coincidently also doesn’t permit Jia Tan’s keys and uses Tukaani repo instead of GitHub, but the resulting liblzma is identical.

Code: [Select]

$ printf 'sshd in arch does not use liblzma. 5.6.1-2 is bit-to-bit identical to 5.6.1-1 except two dozen non-code bytes.\n\n' | sha256sum
c8e7d38a7257c23d1b035f8012c265d87ab12479ddbde60761f1e4c221851271  -

 $ find . -name 'xz-*.pkg.tar.zst' -exec pacman-key --verify {}.sig {} \;
==> Checking ./xz-5.6.1-2-x86_64.pkg.tar.zst.sig... (detached)
gpg: Signature made Thu 28 Mar 2024 22:08:25 CET
gpg:                using EDDSA key 05C7775A9E8B977407FE08E69D4C5AA15426DA0A
gpg: Note: trustdb not writable
gpg: Good signature from "Frederik Schwan <frederik.schwan@linux.com>" [unknown]
gpg:                 aka "Frederik Schwan <frederik@schwan.it>" [unknown]
gpg:                 aka "Frederik Schwan <frederik@tty42.de>" [unknown]
gpg:                 aka "Frederik Schwan <freswa@archlinux.org>" [full]
gpg:                 aka "Frederik Schwan <frederik@schw4n.de>" [unknown]
gpg:                 aka "Frederik Schwan <frederik.schwan@mailbox.org>" [unknown]
==> Checking ./xz-5.6.1-1-x86_64.pkg.tar.zst.sig... (detached)
gpg: Signature made Sat 09 Mar 2024 21:00:37 CET
gpg:                using EDDSA key 0429897DE5F3BDAC537A30696D42BDD116E0068F
gpg: Note: trustdb not writable
gpg: Good signature from "Christian Hesse <eworm@archlinux.org>" [full]
==> Checking ./xz-5.6.1-3-x86_64.pkg.tar.zst.sig... (detached)
gpg: Signature made Mon 01 Apr 2024 22:41:01 CEST
gpg:                using EDDSA key 0429897DE5F3BDAC537A30696D42BDD116E0068F
gpg: Note: trustdb not writable
gpg: Good signature from "Christian Hesse <eworm@archlinux.org>" [full]

 $ sha256sum xz-*.pkg.tar.zst
63b219db0b2f0b6215cc4e4ca64f3fa59b914e7b15bde17c36bf2b21e459c13e  xz-5.6.1-1-x86_64.pkg.tar.zst
17e95679c62d901fc7fe27879ec241d3566603a4eaa6a7a38ccc0e6c28ef60a6  xz-5.6.1-2-x86_64.pkg.tar.zst
609db91285658f0ba12fa472407f0b583fceb6741654fcf0cf0e26312dc46cd0  xz-5.6.1-3-x86_64.pkg.tar.zst

  $ for n in 1 2 3; do tar -xOf xz-5.6.1-$n-x86_64.pkg.tar.zst usr/lib/liblzma.so.5.6.1 >liblzma.so.5.6.1-"$n"; done
  $ sha256sum liblzma.so.5.6.1-*
e47d67ec12cb43715d5ce42ded202f4acea6a1d0172edf58523a3e6d444a5c45  liblzma.so.5.6.1-1
c1a58591631a5bdeff4bd9ac1eae16b6ae392f9c96f17aedae3664448c290f0b  liblzma.so.5.6.1-2
c1a58591631a5bdeff4bd9ac1eae16b6ae392f9c96f17aedae3664448c290f0b  liblzma.so.5.6.1-3
 
 $ diff <(xxd liblzma.so.5.6.1-1) <(xxd liblzma.so.5.6.1-2)
48,49c48,49
< 000002f0: 0300 0000 474e 5500 71f9 a255 f686 4e44  ....GNU.q..U..ND
< 00000300: c325 3a10 dc37 9c25 c8bf b302 0000 0000  .%:..7.%........
---
> 000002f0: 0300 0000 474e 5500 69df 3c77 1c62 8668  ....GNU.i.<w.b.h
> 00000300: 86ef f245 d5b1 5834 540d f808 0000 0000  ...E..X4T.......
12804c12804
< 00032030: 2e36 2e31 2e64 6562 7567 0000 82fd 6f66  .6.1.debug....of
---
> 00032030: 2e36 2e31 2e64 6562 7567 0000 4ad1 cc28  .6.1.debug..J..(

 $ objdump -h liblzma.so.5.6.1-{1,2}

liblzma.so.5.6.1-1:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .note.gnu.property 00000040  00000000000002a8  00000000000002a8  000002a8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .note.gnu.build-id 00000024  00000000000002e8  00000000000002e8  000002e8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .gnu.hash     00000624  0000000000000310  0000000000000310  00000310  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .dynsym       00000ea0  0000000000000938  0000000000000938  00000938  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .dynstr       00000bc4  00000000000017d8  00000000000017d8  000017d8  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .gnu.version  00000138  000000000000239c  000000000000239c  0000239c  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .gnu.version_d 000000ec  00000000000024d8  00000000000024d8  000024d8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .gnu.version_r 000000b0  00000000000025c8  00000000000025c8  000025c8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .rela.dyn     00000870  0000000000002678  0000000000002678  00002678  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .relr.dyn     00000030  0000000000002ee8  0000000000002ee8  00002ee8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .init         0000001b  0000000000003000  0000000000003000  00003000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 11 .text         00021049  0000000000003020  0000000000003020  00003020  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 12 .fini         0000000d  000000000002406c  000000000002406c  0002406c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 13 .rodata       00006c28  0000000000025000  0000000000025000  00025000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 14 .eh_frame_hdr 00000a34  000000000002bc28  000000000002bc28  0002bc28  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 15 .eh_frame     00004540  000000000002c660  000000000002c660  0002c660  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 16 .init_array   00000008  00000000000313f0  00000000000313f0  000313f0  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 17 .fini_array   00000008  00000000000313f8  00000000000313f8  000313f8  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 18 .data.rel.ro  00000718  0000000000031400  0000000000031400  00031400  2**5
                  CONTENTS, ALLOC, LOAD, DATA
 19 .dynamic      00000200  0000000000031b18  0000000000031b18  00031b18  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 20 .got          000002e8  0000000000031d18  0000000000031d18  00031d18  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 21 .data         00000008  0000000000032000  0000000000032000  00032000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 22 .bss          00000008  0000000000032008  0000000000032008  00032008  2**0
                  ALLOC
 23 .comment      0000001b  0000000000000000  0000000000000000  00032008  2**0
                  CONTENTS, READONLY
 24 .gnu_debuglink 0000001c  0000000000000000  0000000000000000  00032024  2**2
                  CONTENTS, READONLY

liblzma.so.5.6.1-2:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .note.gnu.property 00000040  00000000000002a8  00000000000002a8  000002a8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .note.gnu.build-id 00000024  00000000000002e8  00000000000002e8  000002e8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .gnu.hash     00000624  0000000000000310  0000000000000310  00000310  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .dynsym       00000ea0  0000000000000938  0000000000000938  00000938  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .dynstr       00000bc4  00000000000017d8  00000000000017d8  000017d8  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .gnu.version  00000138  000000000000239c  000000000000239c  0000239c  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .gnu.version_d 000000ec  00000000000024d8  00000000000024d8  000024d8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .gnu.version_r 000000b0  00000000000025c8  00000000000025c8  000025c8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .rela.dyn     00000870  0000000000002678  0000000000002678  00002678  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .relr.dyn     00000030  0000000000002ee8  0000000000002ee8  00002ee8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .init         0000001b  0000000000003000  0000000000003000  00003000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 11 .text         00021049  0000000000003020  0000000000003020  00003020  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 12 .fini         0000000d  000000000002406c  000000000002406c  0002406c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 13 .rodata       00006c28  0000000000025000  0000000000025000  00025000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 14 .eh_frame_hdr 00000a34  000000000002bc28  000000000002bc28  0002bc28  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 15 .eh_frame     00004540  000000000002c660  000000000002c660  0002c660  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 16 .init_array   00000008  00000000000313f0  00000000000313f0  000313f0  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 17 .fini_array   00000008  00000000000313f8  00000000000313f8  000313f8  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 18 .data.rel.ro  00000718  0000000000031400  0000000000031400  00031400  2**5
                  CONTENTS, ALLOC, LOAD, DATA
 19 .dynamic      00000200  0000000000031b18  0000000000031b18  00031b18  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 20 .got          000002e8  0000000000031d18  0000000000031d18  00031d18  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 21 .data         00000008  0000000000032000  0000000000032000  00032000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 22 .bss          00000008  0000000000032008  0000000000032008  00032008  2**0
                  ALLOC
 23 .comment      0000001b  0000000000000000  0000000000000000  00032008  2**0
                  CONTENTS, READONLY
 24 .gnu_debuglink 0000001c  0000000000000000  0000000000000000  00032024  2**2
                  CONTENTS, READONLY

# Neither of the sections with differences contain executable code, but
# just to make it clear it would be garbage: disassembled contents of each.

 $ objdump -Sj .note.gnu.build-id liblzma.so.5.6.1-{1,2}

liblzma.so.5.6.1-1:     file format elf64-x86-64


Disassembly of section .note.gnu.build-id:

00000000000002e8 <.note.gnu.build-id>:
 2e8: 04 00                add    $0x0,%al
 2ea: 00 00                add    %al,(%rax)
 2ec: 14 00                adc    $0x0,%al
 2ee: 00 00                add    %al,(%rax)
 2f0: 03 00                add    (%rax),%eax
 2f2: 00 00                add    %al,(%rax)
 2f4: 47                    rex.RXB
 2f5: 4e 55                rex.WRX push %rbp
 2f7: 00 71 f9              add    %dh,-0x7(%rcx)
 2fa: a2 55 f6 86 4e 44 c3 movabs %al,0x3a25c3444e86f655
 301: 25 3a
 303: 10 dc                adc    %bl,%ah
 305: 37                    (bad)
 306: 9c                    pushf
 307: 25 c8 bf b3 02        and    $0x2b3bfc8,%eax

liblzma.so.5.6.1-2:     file format elf64-x86-64


Disassembly of section .note.gnu.build-id:

00000000000002e8 <.note.gnu.build-id>:
 2e8: 04 00                add    $0x0,%al
 2ea: 00 00                add    %al,(%rax)
 2ec: 14 00                adc    $0x0,%al
 2ee: 00 00                add    %al,(%rax)
 2f0: 03 00                add    (%rax),%eax
 2f2: 00 00                add    %al,(%rax)
 2f4: 47                    rex.RXB
 2f5: 4e 55                rex.WRX push %rbp
 2f7: 00 69 df              add    %ch,-0x21(%rcx)
 2fa: 3c 77                cmp    $0x77,%al
 2fc: 1c 62                sbb    $0x62,%al
 2fe: 86 68 86              xchg   %ch,-0x7a(%rax)
 301: ef                    out    %eax,(%dx)
 302: f2 45                repnz rex.RB
 304: d5 b1 58 34 54        addps  (%r28,%r18,2),%xmm6
 309: 0d                    .byte 0xd
 30a: f8                    clc
 30b: 08                    .byte 0x8

 $ objdump -Sj .gnu_debuglink liblzma.so.5.6.1-{1,2}

liblzma.so.5.6.1-1:     file format elf64-x86-64


Disassembly of section .gnu_debuglink:

0000000000000000 <.gnu_debuglink>:
   0: 6c                    insb   (%dx),%es:(%rdi)
   1: 69 62 6c 7a 6d 61 2e imul   $0x2e616d7a,0x6c(%rdx),%esp
   8: 73 6f                jae    79 <XZ_5.0@@XZ_5.0+0x79>
   a: 2e 35 2e 36 2e 31    cs xor $0x312e362e,%eax
  10: 2e 64 65 62 75 67 00 (bad)
  17: 00
  18: 82                    (bad)
  19: fd                    std
  1a: 6f                    outsl  %ds:(%rsi),(%dx)
  1b: 66                    data16

liblzma.so.5.6.1-2:     file format elf64-x86-64


Disassembly of section .gnu_debuglink:

0000000000000000 <.gnu_debuglink>:
   0: 6c                    insb   (%dx),%es:(%rdi)
   1: 69 62 6c 7a 6d 61 2e imul   $0x2e616d7a,0x6c(%rdx),%esp
   8: 73 6f                jae    79 <XZ_5.0@@XZ_5.0+0x79>
   a: 2e 35 2e 36 2e 31    cs xor $0x312e362e,%eax
  10: 2e 64 65 62 75 67 00 (bad)
  17: 00
  18: 4a d1 cc              rex.WX ror $1,%rsp
  1b: 28                    .byte 0x28