Isn't XZ just another example of this?
I feel bad about Lasse Collin, this guy was mentally burned out and needed help, he was vulnerable to this.
Imagine how many projects are now being or already backdoored because of this? Is FOSS in danger right now?
 Shopping Cart Returner Shirt $21.68 |
 DMT Has Friends For Me Shirt $21.68 |
Shopping Cart Returner Shirt $21.68 |
>Imagine how many projects are now being or already backdoored because of this? Is FOSS in danger right now?
everything, code you do not personally audit is by default unsafe. You're just blindly trusting that you are not the target
Even Debian, that is notoriously careful about new packages, pushed the backdoored package to sid (and Fedora pushed to Rawhide). The distribution model is also in a crisis. Hobbyist distros like Arch are unable to audit anything.
Arch (and Gentoo for that matter) weren't vulnerable since they weren't carrying the OpenSSH patch that linked in libsystemd, and it's transitive dependency liblzma, which had the backdoor.
Debian *is* notoriously careful about package updates... in stable. Which they yell loudly from the tops of the hills is the only thing they make any security guarantees at all about, testing and sid they explicitly say "you're on your own, there may be security issues, they may remain unpatched for arbitrary amounts of time, development/testing use only!"
No, it's illegal to not be mentally ill there
The issue is that Debian stable (like all other stable distros) is missing LOTS of security fixes, and I mean the majority of them, including kernel ones. Maybe this is acceptable on a locked down minimal server, but it's not reasonable for desktop use.
What are you talking about?
Debian stable backports security fixes, they don't just sit on an untouched old version.
Anon, I hate to corrupt your innocence, but security backports are a lie.
To begin with, only security bugs that receive a CVE are backported, but many important projects, including the kernel itself, don't get CVE for many security fixes. Then, most of the time (at least in the kernel), backporting consists on simply merging a security patch as is. If it compiles, that's good, and if it doesn't, then an email about it is sent, and that's it, the patch stays unmerged and the LTS branch is simply not patched. And finally, even for properly managed CVEs, there are many that stay unfixed for years: https://security-tracker.debian.org/tracker/status/release/stable
Now click the box that says "hide local scope". If Im not mistaken, you need physical access or alreafy have network access for any other vulns. Only a few vulns are from 2023, the vast majority are from 2024, theres not a single one that is a known remote vuln. Theres 5 or so unknown vulns.
Even if the whole list of unpatched CVEs is "safe", there are the other problems mentioned.
Even Ubuntu can be easily exploited with month-old kernel bugs, just imagine how worse the situation is on Debian stable: https://blog.exodusintel.com/2024/03/27/mind-the-patch-gap-exploiting-an-io_uring-vulnerability-in-ubuntu/
And again, this is without taking in account that there there are many security bugs that don't receive CVEs and therefore are not even considered for backporting. And recently it has become even worse, because the kernel has become an official CVE numbering authority and they've been releasing a massive volume of meaningless CVEs that actually have no security impact (like simply renaming a variable: https://twitter.com/spendergrsec/status/1759724265438322962 ) so now security backport efforts will become even more overstretched and ineffective.
Yeah, Id feel much more secure with bleeding edge updates so some anon/glow/etc can use a private key to ssh into my shit.
If its so easy, setup a Debian Stable box, hack into it remotely, write up a report and make a youtube video showing how you did it ffs. You could be getting Patron bucks
imagine having knowledge of such vulnerability and just using it to make a yt video. shit like that would be worth a small fortune.
Might as well call you Elmer, cause of all the FUD you're spreading.
Then the upstreams should split and bisect their tree so that feature changes go into major versions, and security patches are in point releases. More than once, Debian has had to backport a code fix from an upstream that didn't keep a maintenance release running like fricking morons.
Any GUI application doesn't belong in a security sensitive context, so the chances of large scale interface changes is limited anyway.
In an ideal world, I agree that's how upstream should work. But that's simply not realistic, the real world is a jungle.
These are the current choices:
- Stable: old, tested and stable versions, and a kernel with smaller attack surface, but also many security fixes are missing systemwide.
- Bleeding edge: non-tested, non-reviewed, potentially breaking updates, kernel with larger attack surface, but at least you get all security fixes.
- Mixed: bleeding edge with a delay, IMO the least bad choice for desktop users with the current model (Fedora, SUSE Leap, etc).
- Stable: old backdoor, published cves
- Bleeding edge: new backdoor, glowBlack person 0day for sale
- Mixed: both
Please enlighten us on these security issues moron
See
>Even Debian, that is notoriously careful about new packages
In stable, yes. Broken stuff ends up in testing all the time.
>pushed the backdoored package to sid (and Fedora pushed to Rawhide)
both distros only provide guarantees on their stable branches
sid and rawhide are unstable branches intended for dealing with issues like this
if anything this just proves that rolling release is an insecure model
>that is notoriously careful about new packages
I'm not sure where you heard this but debian is actually known for maintainers lack of care about basically everything and especially security.
many packages are maintained by a very tiny amount of (unpaid) people and many security patches are never pushed to debian stable while the actual upstream patches live in sid/testing (very ironic and non-sensical if security is what you care about).
debian stability is vastly different from rhel stability, the latter is all about keeping the feature set while fixing holes, debian is about freezing everything for two years and praying no critical CVEs are found because they will most likely never be patched.
I don't understand why people keep getting fooled by debian false promises, centos stream or any rhel stable clones are much better if security is what you care about.
I've been keeping up with yocto, debian, rhel and ubuntu CVEs with dependency-track at work and debian is by far the distro that fixes the less things during the entire lifetime of a particular version.
ubuntu is second as they're pay-walling more and more fixes everyday with ubuntu pro, frick them too, redhat is unironically the most diligent when it comes to security and phoronix benchmark with centos stream usually show that while using outdated (and patched) packages sometimes, performances are largely in line with up-to-date distros.
I've been a redhat hater for a long-time before I changed job and became the os gatekeeper/builder at work, now I see how bad of a job the others are doing wrt security.
Thank you Red Hat public relations employee, very cool.
Most CVEs aren't actually a problem. It's inflation of ratings that mean people don't give a shit (however justified) if it's not at the end of the scale.
>10 (which is what XZ was)
>if your machine isn't firewalled, it's either pwned or about to be
>9
>if your software is configured a certain way, and the machine isn't firewalled, you're getting pwned
>8 to like 6
>if you run this crafted input, which might be theoretical, it might execute arbitrary code in a way that might be exploitable
>5 and below
>if you press this button, that only works with either the user running the daemon or as root, the process fandangos on core in a funny way
Not him but that's very true. It's enterprise linux. Their devs actually get paid. Debian devs aren't.
>Their devs actually get paid. Debian devs aren't.
And?
Rhel actually fixes CVE's in a timely manner.
It also reached OpenSUSE Tumbleweed and MicroOS
>pushed the backdoored package to sid
homie, ask yourself why Sid is called "unstable". Stable and oldstable distributions are unaffected, as far as we know.
@99769554
This entire XZ fiasco invalidates everything you said.
It is also proof that point release distribuitons still make sense and that updooting everything CAN and WILL cause trouble.
This is why ArCKh and other rolling release autists are so in panic. Most people just not run these beta versions.
Andres Freund discovered it because he tested on Debian unstable which got it.
If Debian only had stable releases it would have done a lot more damage.
Someone has to run the dangerous versions to keep the rest safe.
And if all you do on a system is test things for future releases then it makes sense to run unstable.
Production code should run on stable and probably LTS especially when dealing with sensitive data.
>pushed it to a branch that is literally named TESTING
>used by 0% of important servers
shocking
Close-source software winning as usual.
>can't audit closed source
even worse
It's fine, the only closed source that matters is from Microsoft and they have the bug finder guy.
programs that you run on windows are not all from micro$oft
Irrelevant. You can sue for damages.
good luck proving negligence or malicious intent
>You can sue for damages.
Lmao, when was the last time you checked EULA? How many people sued Microsoft for WannaCry outbreak?
>The manufacturer or installer, and Microsoft, give no other express warranties, guarantees, or conditions. The manufacturer or installer, and Microsoft, exclude all implied warranties and conditions, including those of merchantability, fitness for a particular purpose, and non-infringement. If your local law does not allow the exclusion of implied warranties, then any implied warranties, guarantees, or conditions last only during the term of the limited warranty and are limited as much as your local law allows. If your local law requires a longer limited warranty term, despite this agreement, then that longer term will apply, but you can recover only the remedies this agreement allows.
>...
>Except for any repair, replacement, or refund the manufacturer or installer, or Microsoft, may provide, you may not under this limited warranty, under any other part of this agreement, or under any theory recover any damages or other remedy, including lost profits or direct, consequential, special, indirect, or incidental damages. The damage exclusions and remedy limitations in this agreement apply even if repair, replacement or a refund does not fully compensate you for any losses, if the manufacturer or installer, or Microsoft, knew or should have known about the possibility of the damages, or if the remedy fails of its essential purpose. Some states and countries do not allow the exclusion or limitation of incidental, consequential, or other damages, so those limitations or exclusions may not apply to you. If your local law allows you to recover damages from the manufacturer or installer, or Microsoft, even though this agreement does not, you cannot recover more than you paid for the software (or up to $50 USD if you acquired the software for no charge).
You were saying?
>moving the goalposts
Right to Privacy is recognized and protected as a fundamental right in my country. No shady EULA phrasing can protect microsoft from litigation in case of any discovered backdoors here.
Try getting ransomware refunded from Microsoft.
You won't audit open source either so it doesn't matter.
Security researchers audit closed source software all the time. It's just more difficult.
Closed-source operating systems and web browsers are all using and based on FOSS.
One of the example that comes to my mind is Microsoft Defender uses 7-Zip to scan archives. What if it is backdoored? Can you, by downloading an archive (not even open it) run malicious code on a system level, bypassing the antivirus?
>inb4 don't use Defender
Windows Explorer also has LZMA support now, so I guess there's some 7-Zip code there too.
It's even worse, because Microsoft isn't auditing the code or isn't sponsoring FOSS, despite they're a 2 trillion dollars company.
SolarWinds
_NSAKEY
EternalBlue
https://techcrunch.com/2023/07/17/microsoft-lost-keys-government-hacked/
this one got found before it made it to stable
>whataboutism
>'winning as usual'
>in fact, is usually losing
'whataboutism' is code for 'shut up and stop giving good counterexamples aaaaaaaaaaahhhhhhhh pleeeeeease'
Closed source can just as easily have backdoors but much lower chances of it being detected.
Check the code yourself
Yes anon
>code you do not personally audit is by default unsafe.
>Software where you by contract are not allowed to review or audit the code
Also this.
Another way to look at it is that consuming dependencies delegates responsibility for behavior, it doesn't eliminate it. If you approach development this way you shouldn't have more than just a couple of dependencies outside the language/OS runtime.
Running untrusted code (e.g. code you didn't audit yourself) is by definition RCE
that doesn't sound like a very useful definition
If I write some code, and I'm like
>dude trust me bro
And you run it on your machine, I've just Remotely Executed my Code on your machine. RCE.
RCE my anus
Code you do personally audit is also unsafe, what now?
the virgin OCD vs the chad nobody cares
>this guy was mentally burned out
I thought it was illegal in Finland to be mentally ill
You are confused, translation error perhaps. It's the other way around.
>I thought it was illegal in Finland to be mentally ill
no, it's mandatory
I was thinking about this very picture when I realized so many of my favorite software is maintained by a nameless, thankless person. Reminds me of Street Lamplighters of the past. So many people relied on them but didn't even know they existed. People like this deserve more praise, and so do people who seed knowledge/learning related torrents. The former are like sniper pothole fillers in cities and the latter are like like illegal librarians for the world
Except lamp lights are inventions of satan to allow homosexuals and w*men to roam the earth at night
Can't the same be said about the internet and all modern infrastructure?
No. Pseud
It looks like I might be moving to zstd, I don't know if it's supported on Linux.
of course its supported
every bit of my system, be it disks, kernel, kernel modules, zswap, zram or initramfs is compressed wtih either zstd or lz4
I will no longer use any software without a committee.
No, because there was no good reason for sshd to depend on xz in the first place.
This is just an example of dependency bloat making everything shit.
yes, minimalists were right again
we need a solid base before building higher
sadly this goes against short term economic gains
but we can still fight for a world where our tools don't break so easily and handle so clumsily
investigate and sponsor clean slate solutions
look into driver dev to help with ares/helios
try to promote strictness, correctness and vigilant quality standards at your workplace and don't back down when someone is trying to haphazardly add technical dept for supposed productivity gains
software isn't in danger if programmers as a whole manage to get a better sense of responsibility and make deliberate designs instead of making it up as we go, trend-chasing and viewing dependencies and the ecosystem as just free code
Project Oberon vindicated A-FRICKING-GAIN.
muh worse is better doe if it werks it werks ship it
Welcome to the FreeBSD team.
>bloatstodon
>tranime
>reddit quoting
>minimalist
opinion discarded
Don't worry about buying the ads, Drew. We've got your back, now and forever. You just worry about pulling us all forward.
>Lasse Collin
that's pretty sus name
t. fin
Probably a dirty swede.
t. Scanian
The problem wasn't even that he passed the buck, it was that he passed the buck to a chink midwit with terrible opsec.
As soon as he started openly talking about his personal problems a bunch of accounts started popping up telling him to give up the project to the chink
What a cohencidence!
many such cases
autists are incredibly vulnerable to glowBlack personing, they don't understand it and can't recognize it
The solution that no one will take is to just not accept projects from israelites or chinks as they're self-interested and fiercely loyal to their actual homeland, rats born in a barn - not a stallion, etc. but no one will go for that even though it's exactly what everyone is thinking.
It's crazy but people are trying to suppress the knowledge that the dude was even Chinese because "muh racism".
That's not surprising at all, really.
Just like the UK and those sex rings.
>oh no, we can't say it was all those Pakis, it'd be racist 🙁
>chink midwit
No that wasn't a midwit at all.
half of them are gay furries and half of them are christian conservatives, which is way funnier tbqh
the two most autistic demographics
bad meme
furries are notoriously bad coders
like abhorrently so
who said the narrow and critically important program was well made?
not that I know anything about this incident, but it looks like someone did a social engineer on him to get access to the private files. Happened to me in 2021 and all they got was my fetish porn.
>playing some private wow server
>one of the biggest around
>find out dev is literally the biggest furgay fursuit fursona type homosexual
>instantly quit
also
>ehentai is literal run by ponygays
>hates his fellow autists
you're a pedobait tranime poster thoever
reminder that none of this would be an issue if everything was a web browser
we suffer because of the 4gb ram Thinkpad x69 users
Maybe. But this ijs just another example of what happened to the OpenSSL project e.g. Heartbleed.
But that was just an innocent mistake compared to an threat actor playing the long game
mirror
It's worse, it's an indictment of the whole Linux package ecosystem (turns out updooting every single dependency system-wide opens up a LOT of opportunities to introduce backdoors), the whole Linux governance model (systemD got there basically via squatting, has proven to be a security nightmare, yet it won't be forked let alone abandoned and Poettering will face no consequence), and the whole Linux auditing process (backdoor snuck through all "standard" checks and was only caught by a random user noticing weird CPU usage).
Now watch as Microsoft takes the opportunity to double down on their moronation.
>muh sysvinit
All modern digital infrastructure is kept alive by my anti-troon activism.
It's not thankless tho.
>corpo
go back to playing cyberjunk 2077 you insufferable reddit homosexual
except foss backdoors are worse because ivan has access to your pc, not the NSA.
in closed source software NSA might have access to your pc but won’t burn it on a schizo to steal his xmr wallet.
security by obscurity is literally the only way. look at openbsd. now that linux is more popular the backdoors get burned one by one.
What about cases when NSA spying tools leaked to botnet owners? Can't botnet owners install their own vulnerabilities by paying insiders in these companies?
Imagine that this case happened with closed source. A guy found strange behaviour in ssh and basically hits the wall. All he can do is raise ticket in supplier's system and wait few weeks for an answer.
He's just a degenerate coomer. The lesson here is to do NoFap.
bruh
Holy shit. You can upload entire movies to Twi/X now?
2 and a half hours of hardcore asians in there. Thanks, Elon!
QRD on how this is a vulnerability?
t. Opsec noob and hardcore coomer
Well it can confirm a name or email you already know but isn't sure about.
the fricking chinks are at it again, gotta nuke their shit
yes it is. it's insane that billion dollar companies are dependent on a freetard's unpaid hobby project. if a microsoft employee had not noticed this by coincidence, it would have even ended up in google and Amazon production servers.
i don't think the nsa is concerned about backdooring their own servers
https://www.mail-archive.com/[email protected]/msg00568.html
>Jigar Kumar
Two guesses which shithole this pajeet is from. Lmao. They are always so fricking rude, uneducated and entitled. The end of the british empire was a mistake.
This was a sick puppet account created only for the purpose of harassing the dev to hand over maintainership they have no other posts anywhere.
Maybe. It's probably a real pajeet though. They really do act like that.
How do you know that? That is just his unverified claims, he could have been working wilingly with chinese hackers/spies for that massive payoff
>unfunny stickmen webcomic
Fun fact, in the early days of Wikipedia there was a vandal known as Grawp who almost destroyed the Mediawiki software powering Wikipedia, he used a lot of exploits to do serious vandalism. If it wasn't for the development of the abuse filter, WIkipedia could have been overrun with vandalbots by now.
I don't. Why did xz need changes at all? What is xz missing?
a backdoor
Exactly. So I ask again, why is software that basically cannot fundamentally change due to its nature, need continuous maintenance? At best I can see people bike shedding hand written vectorization, but wtf?
Like, why did xz need support for some LSM like landlock? Who fricking cares? Most users are feeding bytes into xz from a pipe anyhow.
security updates to fix the previous backdoor
you don't want to be insecure do you?
>NSA
tongue my asus
scalding hazard
new and exciting features!
>t. state sponsored actor
I wonder how did fedora maintainers fell for that zero questions asked
It is tempting at first to assume that there are many backdoors like this out there. But the fact that the first known backdoor of this kind and impact was detected so quickly may indicate, in a single anecdotal example kind of way, that keeping something like this hidden could be unlikely.
This incident shows that a sophisticated backdoor is itself so complex that things are likely to go wrong just like with all other complex software. There's the valgrind errors stuff due to assumptions that didn't hold everywhere, and the performance issue that revealed this backdoor. If you roll out a backdoor like this to millions of systems some of your assumptions will probably break even if it's otherwise super well developed and tested, so someone will trip over it and the backdoor is likely to be found.
It's easy to argue that we got lucky with the performance issue and how it helped find the backdoor, but there are many other mechanisms that could have revealed it. If the backdoor calls home (which this one apparently didn't) it would have shown up in firewall logs, intrusion detection systems, etc. and someone would likely have seen and investigated it at some point after it has been used.
>Imagine how many projects are now being or already backdoored because of this? Is FOSS in danger right now?
already assumed this was the case for years
their build system was insane. they were basically asking for it.
That's autotools in a nutshell
my favorite part about this is that the clear takeaway is that these codebases are architected like shit and these build processes used to facilitate said shitty architecture is a terrible idea
but you just know that's not what anybody is going to take away from this. we're going to plow right on ahead into a nightmare future of outrageously complicated ecosystems. software has metastasized.
Letting builds be linked against test resources is a design defect to begin with, and the fact that this is easy/trivial/widely-accepted is a general indication of the engineering culture problems around C.
Nobody in Java world is linking against test resources in prod, and a sanely designed build system should in fact make this extremely difficult. That shit went away in the maven/gradle days - which is for a reason, ant is basically makefiles for Java, gradle/maven are a build system not a pile of scripts. And that transition happened 20 years ago!
If you can’t even prevent a test resource being linked into a final build you are not serious. I don’t care about legacy whatever, that’s an obvious baseline metric for security culture/build engineering.
Maybe not “prevent” but like, tooling should absolutely make it blindingly obvious that you’re violating best-practices by disabling scoping rules or including unusual source/resource roots, etc.
C has never moved past the 1970 mindset of build being a pile of scripts with a superstructure bolted on. Just like Ant. Even the attempts to fix C’s build are just better ways to programmatically generate better bash scripts to keep you going off the rails.
i like that your takeaway from "they're fricking stupid for overcomplicating their build process" is "we need even more complex build processes with many more abstractions". the problem is that you can't beat the old school. the 1970s way of doing things is bullet-proof, simple, and universal. it was not and never was a "C" thing. this modern shit of meta build systems like autotools, cmake, etc. is dogshit and has nothing to do with the proper way to go about things.
and no, i'm never going to use a build system that relies on a DSL. I don't give a shit. you will deal with me manually patching shit together in shell scripts and you'll enjoy every second of it you little nocode cuckold.
no need to get so defensive about your shitty ghetto build system. just learn cmake.
You mean xz?
It was most likely deliberate and well planned - their build system made hard to understand on purpose so nobody would notice when malicious code was inserted.
Feels good using a distro that doesn't run systemd.
This is just one of the many exploits that will make use of that bloated piece of shit, directly or indirectly.
which distro would that be?
do you run dbus? do you run elogind?
you can’t escape systemd on linux. if you have ever installed a desktop environment it will require some part pf systemd.
just because it doesn’t say systemd in htop doesn’t mean you don’t run a part of it. some parts of it are good, like sustemd-boot is much simpler than the hell that is grub
not even on freebsd you can’t escape dbus
not him but something like artix
your post makes no sense and that's coming from someone who uses systemd
also, use EFISTUB
systemd is not just one process.
consolekit, udev, logind. all pf these are part of EVERY distro.
ConsoleKit is not systemd, but it is considered "deprecated" and DEs recommend switching to logind
seatd is a newer minimalist alternative
None of these are required.
udev was not originally part of systemd
udev was written by Linus' #2, Greg Kroah Hartman
Lennart became maintainer and took it hostage under systemd
There are alternatives, BusyBox has mdev, s6 made an alternative "mdevd"
You can also bring up all the /dev interfaces with scripts, but that tends to be discouraged
You got it right. It's artix.
Sure, systemd has components that are separate. From those, systemd-boot is actually okay unlike the utter POS that is GRUB, but I use syslinux anyway so whatever.
But running a distro with some of these individual components heavily reduces the attack surface compared to running normal systemd. (also, booting with a proper init system is fast, whereas systemd is slow as frick on older toasters).
>do you run dbus? do you run elogind?
nope.
>if you have ever installed a desktop environment it will require some part pf systemd.
I don't use a de because i'm not a moron
You're post is wrong on so many levels.
- dbus is not part of systemd
- elogind is not required unless you want a display manager (I log in from a TTY), also seatd is a minimalist alternative
- no desktop environment requires systemd, only GNOME did but it was patched by Gentoo and merged upstream
- systemd-boot is not good: it only supports UEFI, it's bloat over a simple efistub with all the drawbacks (like requiring your kernel be in the efi partition)
- GRUB may be bloated, but it comes with a lot of features like BIOS support, encryption/decryption, can boot kernels on ext4
>systemd-boot is not good: it only supports UEFI, it's bloat over a simple efistub with all the drawbacks (like requiring your kernel be in the efi partition)
>GRUB may be bloated, but it comes with a lot of features like BIOS support, encryption/decryption, can boot kernels on ext4
homosexual contrarian take, systemd-boot just werks unless you need something unusual like booting from btrfs snapshots.
>Ubuntu still hasn't pushed out the patch
>Ubuntu won't take the patch pushed out by Debian to its stable channel
wtf
ubuntu is different from debian.
>The affected version of xz-utils was only in noble-proposed, and
was removed before migrating to noble itself. No released
versions of Ubuntu were affected by this issue.
https://ubuntu.com/security/CVE-2024-3094
>closed source:
>jia tan can't commit code to production
>open source:
>jia tan can frick your mother in the sphincter
https://en.wikipedia.org/wiki/SolarWinds#2019%E2%80%932020_supply_chain_attacks
has the whole core-js thing been resolved? Did that maintainer ever make bank and get some help from other devs/companies?
>putting a backdoor in an open source dependency for OpenSSH
fricking impressive. I mean, just wow.
core-js?
It's quite funny, fedora and debian were catching bugs from xz on 5.6.0 and 5.6.1-0 but they were just writing back to xz "please fix it fast because our tests are failing"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708
https://bugzilla.redhat.com/show_bug.cgi?id=2267598
very very fascinating, thanks for linking that
>krygorin4545@burner
>misoeater91@burner
Jesas.
>fedora and debian were catching bugs from xz
>"p-pls fix..?"
>microsoft chad had to intervene to get shit uncovered
lmaoin hard @ open source troony code-jannies
anon@fbi:~$ apt list | wc -l
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
58747
>why do repo jannies not try to find backdoors in upstream packages?
>microsoft chad
what a great company, what a great dev. I fricking love Microsoft
tbf as a maintainer I wouldn't really expect something like this to be malware, I'd probably also think it's just some bug