What we know about the xz Utils backdoor that almost infected the world
1–10 of 336 posts
Re: What we know about the xz Utils backdoor that almost infected the world
#2I didn't realize it was a Microsoft engineer that works on Azure Postgres that found the issue.
Thanks, Microsoft, I like Azure now.
Re: What we know about the xz Utils backdoor that almost infected the world
#3I didn't realize it was a Microsoft engineer that works on Azure Postgres that found the issue. Thanks, Microsoft, I like Azure now.
And I think people should now look at all oddities with Valgrind. Since that is how the issue got discovered. And then look at the problematic library and look for similar outliers of fake personas taking over a project.
It seems it is common practice for people to ignore these errors.
Re: What we know about the xz Utils backdoor that almost infected the world
#4Are we ever going to figure out who Jia Tan is?
Re: What we know about the xz Utils backdoor that almost infected the world
#5I didn't realize it was a Microsoft engineer that works on Azure Postgres that found the issue. Thanks, Microsoft, I like Azure now.
And I think people should now look at all oddities with Valgrind. Since that is how the issue got discovered. And then look at the problematic library and look for similar outliers of fake personas taking over a project. It seems it is common practice for people to ignore these errors.
Valgrind will tell you about memory leaks and won't always behave the way it did here when there's a backdoor. In this case it just so happened that valgrind was throwing errors because the stack layout didn't match what the exploit was expecting. Otherwise valgrind would have probably worked without issues.
Re: What we know about the xz Utils backdoor that almost infected the world
#6I didn't realize it was a Microsoft engineer that works on Azure Postgres that found the issue. Thanks, Microsoft, I like Azure now.
And I think people should now look at all oddities with Valgrind. Since that is how the issue got discovered. And then look at the problematic library and look for similar outliers of fake personas taking over a project. It seems it is common practice for people to ignore these errors.
Do you remember the Debian openssl flaw? Okay, it's almost 20 years old now, so you may have forgotten, or you could be too young, I don't know. But it was caused by someone attempting to fix an oddity found by valgrind.
Re: What we know about the xz Utils backdoor that almost infected the world
#7Earlier quoted context omitted.
And I think people should now look at all oddities with Valgrind. Since that is how the issue got discovered. And then look at the problematic library and look for similar outliers of fake personas taking over a project. It seems it is common practice for people to ignore these errors.
Valgrind will tell you about memory leaks and won't always behave the way it did here when there's a backdoor. In this case it just so happened that valgrind was throwing errors because the stack layout didn't match what the exploit was expecting. Otherwise valgrind would have probably worked without issues.
The idea is not "valgrind will detect all tomfoolery". The idea here is "if valgrind detects something it may be an indication of tomfoolery.'
Re: What we know about the xz Utils backdoor that almost infected the world
#8Earlier quoted context omitted.
And I think people should now look at all oddities with Valgrind. Since that is how the issue got discovered. And then look at the problematic library and look for similar outliers of fake personas taking over a project. It seems it is common practice for people to ignore these errors.
Valgrind will tell you about memory leaks and won't always behave the way it did here when there's a backdoor. In this case it just so happened that valgrind was throwing errors because the stack layout didn't match what the exploit was expecting. Otherwise valgrind would have probably worked without issues.
> the stack layout didn't match what the exploit was expecting.
What does that mean? Why is the exploit expecting something from the stack layout and why does valgrind complain?
Re: What we know about the xz Utils backdoor that almost infected the world
#9Earlier quoted context omitted.
Valgrind will tell you about memory leaks and won't always behave the way it did here when there's a backdoor. In this case it just so happened that valgrind was throwing errors because the stack layout didn't match what the exploit was expecting. Otherwise valgrind would have probably worked without issues.
The idea is not "valgrind will detect all tomfoolery". The idea here is "if valgrind detects something it may be an indication of tomfoolery.'
Exactly.
Also remember this
>> odd valgrind complaint in automated testing of postgres
I would imagine compiling a list of odd complaints may yield something , or nothing at all.
Re: What we know about the xz Utils backdoor that almost infected the world
#10Are we ever going to figure out who Jia Tan is?
No