Hacker News Reader

Comment by b112 | Hacker News Reader

Yikes indeed. This fix is being rolled out very fast, but what about the entire rest of the codebase? And scripts? I mean, years of access? I'd trust no aspect of this code until a full audit is done, at least of every patch this author contributed.

(note: not referring to fedora here, a current fix is required. But just generally. As in, everyone is rolling out this fix, but... I mean, this codebase is poison in my eyes without a solid audit)

View on HN

This seems to be the account, correct me if wrong (linked from the security email commit link):

https://github.com/JiaT75

I hope authors of all these projects have been alerted.

STest - Unit testing framework for C/C++. Easy to use by simply dropping stest.c and stest.h into your project!

libarchive/libarchive - Multi-format archive and compression library

Seatest - Simple C based Unit Testing

Everything this account has done should be investigated.

Woha, is this legit or some sort of scam on Google in some way?:

https://github.com/google/oss-fuzz/pull/11587

edit: I have to be missing something, or I'm confused. The above author seems to be primary contact for xz? Have they just taken over?? Or did the bad commit come from another source, and a legit person applied it?

A bit confused here.

The concern about other projects is fine, but let's be careful with attacks directed at the person.

Maybe their account is compromised, maybe the username borrows the identity of an innocent person with the same name.

Focus on the code, not people. No point forming a mob.

(e: post above was edited and is no longer directed at the person. thanks for the edit.)

It's important to focus on people, not just code, when suspecting an adversary. Now, I have no idea if this is the right account, and if it has recently been compromised/sold/lost, or if it has always been under the ownership of the person who committed the backdoor. But IF this is indeed the right account, then it's important to block any further commit from it to any project, no matter how innocuous it seems, and to review thoroughly any past commit. For the most security-conscious projects, it would be a good idea to even consider reverting and re-implementing any work coming from this account if it's not fully understood.

An account that has introduced a backdoor is not the same thing as an account who committed a bug.

I agree we should look at the account and its contributions, I make a distinction between the account and the person.

Sometimes the distinction is not meaningful, but better safe than sorry.

Oh, agreed then.

They appear to have moved carefully to set this up over the course of weeks by setting up the framework to perform this attack.

I would now presume this person to be a hostile actor and their contributions anywhere and everywhere must be audited. I would not wait for them to cry 'but my bother did it', because an actual malicious actor would say the same thing. The 'mob' should be pouring over everything they've touched.

Audit now and audit aggressively.

My above post shows the primary domain for xz moving from tukaani.org to xz.tukaani.org. While it's hosted on github:

$ host xz.tukaani.org

host xz.tukaani.org is an alias for tukaani-project.github.io.

And originally it was not:

$ host tukaani.org

tukaani.org has address 5.44.245.25 (seemingly in Finland)

It was moved there in Jan of this year, as per the commit listed in my prior post. By this same person/account. This means that instead of Lasse Collin's more restrictive webpage, an account directly under the control of the untrusted account, is now able to edit the webpage without anyone else's involvement.

For example, to make subtle changes in where to report security issues to, and so on.

So far I don't see anything nefarious, but at the same time, isn't this the domain/page hosting bad tarballs too?

> tukaani.org has address 5.44.245.25 (seemingly in Finland)

Hetzner?

No:

    route:          5.44.240.0/21
    descr:          Zoner Oy
    origin:         AS201692
    mnt-by:         MNT-ZONER
    created:        2014-09-03T08:09:00Z
    last-modified:  2014-09-03T08:09:00Z
    source:         RIPE

Interesting, seems to be a tiny finnish hosting company: https://www.zoner.fi/english/

It's Finnish, Oy is short for "Osake Yhtiö" (share-association, basically a LLC), seems to be registered/hosted at https://www.zoner.fi/

So probably Suojelupoliisi, Finnish Security and Intelligence Service is behind all this

Zoner is a Finnish web hosting company, which has a history of providing hosting for Finnish open source projects, and the original maintainer (and most of the original crew) is Finnish as well. Nothing weird here.

For what it's worth, tukaani is how you spell toucan (the bird) in Finnish, and Lasse is a common Finnish name; the site being previously hosted in Finland is very plausible.

Yeah according to their website[0] it looks like majority of the past contributors were Finnish so nothing odd about the hosting provider. On the same page it says that Jia Tan became co-maintainer of xz in 2022.

0: https://tukaani.org/about.html

This account changed the instructions for reporting security issues in the xz github as their very last commit:

    commit af071ef7702debef4f1d324616a0137a5001c14c (HEAD -> master, origin/master, origin/HEAD)
    Author: Jia Tan <jiat0218@gmail.com>
    Date:   Tue Mar 26 01:50:02 2024 +0800

        Docs: Simplify SECURITY.md.

    diff --git a/.github/SECURITY.md b/.github/SECURITY.md
    index e9b3458a..9ddfe8e9 100644
    --- a/.github/SECURITY.md
    +++ b/.github/SECURITY.md
    @@ -16,13 +16,7 @@ the chance that the exploit will be used before a patch is released.
     You may submit a report by emailing us at
     [xz@tukaani.org](mailto:xz@tukaani.org), or through
     [Security Advisories](https://github.com/tukaani-project/xz/security/advisories/new).
    -While both options are available, we prefer email. In any case, please
    -provide a clear description of the vulnerability including:
    -
    -- Affected versions of XZ Utils
    -- Estimated severity (low, moderate, high, critical)
    -- Steps to recreate the vulnerability
    -- All relevant files (core dumps, build logs, input files, etc.)
    +While both options are available, we prefer email.

     This project is maintained by a team of volunteers on a reasonable-effort
     basis. As such, please give us 90 days to work on a fix before

Seems innocuous, but maybe they were planning further changes.

> Seems innocuous, but maybe they were planning further changes.

Seems like an attempt to get 90 days of "use" of this vulnerability after discovery. If they only had checked performance before!

No, they just removed the bullet points about what to include in a report. The 90 days part was in both versions.

True, but the "talk only to me" part was new, I think.

They didn't add any content, it was a pure removal commit

Yes. An incomplete report allows for dragging out "fixing" the issue longer.

The website change reminds me a bit of lbzip2.org https://github.com/kjn/lbzip2/issues/26#issuecomment-1582645... Although, at the moment, it only seems to be spam. The last commit was 6 years ago, so I guess that's better than a maintainer change...

If the owner of the account is innocent and their account was compromised, it's on them to come out and say that. All signs currently point to the person being a malicious actor, so I'll proceed on that assumption.

Does the person exist at all? Maybe they're a persona of a team working at some three letter agency...

Or for some three letter party.

Probably not. I did some pattern of life analysis on their email/other identifiers. It looks exactly like when I set up a burner online identity- just enough to get past platform registration, but they didn't care enough to make it look real.

For example, their email is only registered to GitHub and Twitter. They haven't even logged into their Google account for almost a year. There's also no history of it being in any data breaches (because they never use it).

Burn the witch.

It would be interesting to hear the whole arc of social engineering behind getting access to the repo. Although, as a maintainer of a large-ish OSS project myself, I know that under a lot of burden any help will be welcomed with open arms, and I've never really talked about private stuff with any of them.

did you find the Twitter account associated to Jia's email?

Found it by myself! https://twitter.com/JiaT03868010

Oh no, not libarchive! GitHub search shows 6 pull requests were merged back in 2021.

https://github.com/search?q=repo%3Alibarchive%2Flibarchive+j...

It does look innocent enough though. Let's hope there's no unicode trickery involved...

Maybe not. They removed safe_fprintf() here and replaced it with the (unsafe) fprintf().

https://github.com/libarchive/libarchive/commit/e37efc16c866...

If libarchive is also backdoored, would that allow specifically crafted http gzip encoded responses to do bad things?

What software is using libarchive to decode HTTP responses?

I don't know, way outside my domain. Possibly none I guess?

FreeBSD's archive tools are built on top of libarchive IIRC. Not sure about the other BSDs.

Well for one, the Powershell script I just wrote to build all the 3rd-party library dependencies for a video game.

tar.exe was added to Windows this January, sourced from libarchive: https://learn.microsoft.com/en-us/virtualization/community/t...

Unlike the GNU tar I'm used to, it's actually a "full fat" command line archiving tool, compressing & decompressing zip, xz, bz2 on the command-line - really handy :-O

No. There's no good reason HTTP response decoding would ever be implemented in terms of libarchive; using libz directly is simpler and supports some use cases (like streaming reads) which libarchive doesn't.

EDIT: Ahh, I was wrong and missed the addition of "strerror"

The PR is pretty devious.

JiaT75 claims is "Added the error text when printing out warning and errors in bsdtar when untaring. Previously, there were cryptic error messages" and cites this as fixing a previous issue.

https://github.com/libarchive/libarchive/pull/1609

However it doesn't actually do that!

The PR literally removes a new line between 2 arguments on the first `safe_fprintf()` call, and converts the `safe_fprintf()` to unsafe direct calls to `fprintf()`. In all cases, the arguments to these functions are exactly the same! So it doesn't actually make the error messages any different, it doesn't actually solve the issue it references. And the maintainer accepted it with no comments!

But I see the "strerror" call is added

reread it...

It does remove the safe prefixes... But it also adds one print statement to "strerror()", which could plausibly give better explanations for the error code...

The only suspicious thing here is the lack for safe_ prefix (and the potential for the strerror() function to already be backdoored elsewhere in another commit)

That seems to be fine. safe_fprintf() takes care of non-printable characters. It's used for archive_entry_pathname, which can contain them, while "unsafe" fprintf is used to print out archive_error_string, which is a library-provided error string, and strerror(errno) from libc.

We know there's long-cons in action here, though. This PR needn't be the exploit. It needn't be anywhere _temporally_ close to the exploit. It could just be laying groundwork for later pull requests by potentially different accounts.

Exactly. If we assume the backdoor via liblzma as a template, this could be a ploy to hook/detour both fprintf and strerror in a similar way. Get it to diffuse into systems that rely on libarchive in their package managers.

When the trap is in place deploy a crafted package file that appears invalid on the surface level triggers this trap. In that moment fetch the payload from the (already opened) archive file descriptor, execute it, but also patch the internal state of libarchive so that it will process the rest of the archive file as if nothing happened, and the desired outcome also appearing in the system.

Assuming there isn't another commit somewhere modifying a library-provided error string or anything returned by libc. There is all kinds of mischief to be had there, which may or may not have already happened, e.g. now you do some i18n and introduce Unicode shenanigans.

That looks like a repo that would sound alarms if you look at it from a security standpoint.

JiaT75 also has commits in wasmtime according to https://hachyderm.io/@joeyh/112180082372196735

per https://hachyderm.io/@bjorn3/112180226784517099, "The only contribution by them to Wasmtime is a doc change. No actual code or binary blobs have been changed by them."

Just a documentation change, fortunately:

https://github.com/bytecodealliance/wasmtime/commits?author=...

They've submitted little documentation tweaks to other projects, too; for example:

https://learn.microsoft.com/en-us/cpp/overview/whats-new-cpp...

I don't know whether this is a formerly-legitimate open source contributor who went rogue, or a deep-cover persona spreading innocuous-looking documentation changes around to other projects as a smokescreen.

Minor documentation change PRs is a well known tactic used to make your GitHub profile look better (especially to potential employers).

He could be doing the same thing for other reasons; nobody really digs into anything very deep so I could see someone handing over co-maintenance to a project based on a decent looking Github graph and some reasonability.

Consider the possibility those type of submissions were part of the adversary's strategy in order to make their account appear more legitimate rather than appearing out of nowhere wanting to become the maintainer of some project.

> The above author seems to be primary contact for xz?

They made themselves the primary contact for xz for Google oss-fuzz about one year ago: https://github.com/google/oss-fuzz/commit/6403e93344476972e9...

A SourceGraph search like this shows https://sourcegraph.com/search?q=context:global+JiaT75&patte...

- Jia Tan <jiat75@gmail.com>

- jiat75 <jiat0218@gmail.com>

``` amap = generate_author_map("xz")

        test_author = amap.get_author_by_name("Jia Cheong Tan")

        self.assertEqual(
            test_author.names, {"Jia Cheong Tan", "Jia Tan", "jiat75"}

        )

        self.assertEqual(

            test_author.mail_addresses,

            {"jiat0218@gmail.com", "jiat75@gmail.com"}

        )

```

additionally, even though the commit messages they've made are mostly plain, there may be features of their commit messages that could provide leads, such as his using what looks like a very obscure racist joke of referring to a gitignore file as a 'gitnigore'. There's barely a handful of people on the whole planet making this 'joke'.

Can you point to where you saw that racist joke?

I don't see anything at https://sourcegraph.com/search?q=context:global+author:jiat0...

first commit made in one of JiaT75's other repos https://github.com/JiaT75/STest/commits/master/

Thank you. If you wouldn't have explained the background, I totally would've thought that this is just an innocent typo.

(I still think it's like... 60% a typo? don't know)

Anyhow, other people called the CCing of JiaT75 by Lasse suspicious:

https://news.ycombinator.com/item?id=39867593

https://lore.kernel.org/lkml/20240320183846.19475-2-lasse.co...

Someone pointed out the "mental health issues" and "some other things"

https://news.ycombinator.com/item?id=39868881

https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.h...

Lasse is of course a Nordic name, and the whole project has a finnish name and hosting

https://news.ycombinator.com/item?id=39866902

If I wanted to go rogue and insert a backdoor in a project of mine, I'd probably create a new sockpuppet account and hand over management of the project to them. The above is worringly compatible with this hypothesis.

OTOH, JiaT75 did not reuse the existing hosting provider, but rather switched the site to github.io and uploaded there old tarballs:

https://github.com/tukaani-project/tukaani-project.github.io...

If JiaT75 is an old-timer in the project, wouldn't they have kept using the same hosting infra?

There are also some other grim possibilities: someone forced Lasse to hand over the project (violence or blackmailing? as farfetched as that sounds)... or maybe stole Lasse devices (and identity?) and now Lasse is incapacitated?

Or maybe it's just some other fellow scandinavian who pretended to be chinese and got Lasse's trust. In which case I wish Lasse all the best, and hope they'll be able to clear their name.

Is the same person sockpuppeting Hans Jansen? It's amusing (but unsurprising) that they are using both german-sounding and chinese-sounding identities.

That said, I don't think it's unreasonable to think that Lasse genuinely trusted JiaT75, genuinely believed that the ifunc stuff was reasonable (it probably isn't: https://news.ycombinator.com/item?id=39869538 ) and handed over the project to them.

And at the end of the day, the only thing linking JiaT75 to a nordic identity is a nordic racist joke which could well be a typo. People already checked the timezone of the commits, but I wonder if anyone has already checked the time-of-day of those commits... does it actually match the working hours that a person genuinely living (and sleeping) in China would follow? (of course, that's also easy to manipulate, but maybe they could've slip up)

Anyhow, I guess that security folks at Microsoft and Google (because of JiaT75 email account) are probably going to cooperate with authorities on trying to pin down the identity of JiaT75 (which might not be very useful, depending on where they live).

> does it actually match the working hours that a person genuinely living (and sleeping) in China would follow?

No, it doesn't:

https://play.clickhouse.com/play?user=play#U0VMRUNUIHRvSG91c...

The vast majority of their Github interactions are between 12.00 UTC and 18.00 UTC

It's worth mentioning Lasse is still online in the Libera chat room, idling. Nothing's been said.

From elsewhere in the comments:

https://news.ycombinator.com/item?id=39874621

> He came on IRC, he seemed ok. He did some cleanup of access and signed off for easter.

i think it's American trauma. outside of the Western hemisphere, sexist and racist jokes are just jokes

Pretty sure this is just a typo...

I tried to understand the significance of this (parent maybe implied that they reused a completely fictitious identity generated by some test code), and I think this is benign.

That project just includes some metadata about a bunch of sample projects, and it links directly to a mirror of the xz project itself:

https://github.com/se-sic/VaRA-Tool-Suite/blob/982bf9b9cbf64...

I assume it downloads the project, examines the git history, and the test then ensures that the correct author name and email addresses are recognized.

(that said, I haven't checked the rest of the project, so I don't know if the code from xz is then subsequently built, and or if this other project could use that in an unsafe manner)

Interesting thing about this jiat75@gmail.com email is that it seems to not exist?

The google account: "Couldn't find your Google Account"

The email: "50 5.1.1 The email account that you tried to reach does not exist"

But then when you try to register it says it's taken.

Was it disabled?

I'd say at this point all major tech companies, ISPs and authorities should have more enough information and disabling and freezing their accounts would be the first step.

This can happen if you delete your old gmail account. Source: I deleted a gmail account I shouldn't have years ago. It will say taken if it previously existed, and was deleted.

>Woha, is this legit or some sort of scam on Google in some way?:

I work on OSS-Fuzz.

As far as I can tell, the author's PRs do not compromise OSS-Fuzz in any way.

OSS-Fuzz doesn't trust user code for this very reason.

It looks more like they disabled a feature of oss-fuzz that would've caught the exploit, no?

That's what people are saying though I haven't had the chance to look into this myself.

Fuzzing isn't really the best tool for catching bugs the maintainer intentionally inserted though.

It's more likely that fuzzing would blow up on new code and they wanted an excuse to remove it.

After all, if it hadn't had a performance regression (someone could submit a PR fixing whatever slowed it down, heh) it still wouldn't be known.

There is also a variety of new, parallelized implementations of compression algorithms which would be good to have a close look at. Bugs causing undefined behaviour in parallel code are notoriously hard to see, and the parallel versions (which are actually much faster) could be take the place of well-established programs which have earned a lot of trust.

Well that account also did most of the releases since 5.4.0.

+1 Can see from project homepage http://web.archive.org/web/20240329165859/https://xz.tukaani... they have some release responsibility from 5.2.12.

> Versions 5.2.12, 5.4.3 and later have been signed with Jia Tan's OpenPGP key . The older releases have been signed with Lasse Collin's OpenPGP key .

It must be assume that before acquiring that privilege, they also contributed code to project. Probably most was to establish respectable record. Still could be malicious code going back someways.

Looks like the Jia Tan OpenPGP key was replaced a few months ago as well: https://github.com/tukaani-project/tukaani-project.github.io...

Reply on news.ycombinator.com