91–100 of 236 posts
To me, the biggest part of this story is: 1. Over two years ago, this was apparently detected automatically by the syzkaller kernel fuzzer, and automatically reported on its public mailing list. [1] 2. Over a year and a half ago, it was apparently fixed in the upstream kernel. [2] 3. It was apparently never merged back to various "stable" kernels, leading to the recent CVE. [3] So you might read that and think "Ok, p…
To me, the biggest part of this story is: 1. Over two years ago, this was apparently detected automatically by the syzkaller kernel fuzzer, and automatically reported on its public mailing list. [1] 2. Over a year and a half ago, it was apparently fixed in the upstream kernel. [2] 3. It was apparently never merged back to various "stable" kernels, leading to the recent CVE. [3] So you might read that and think "Ok, p…
It's bad enough that syzbot finds fifty serious bugs per hour, but I'll relay a personal anecdote. Earlier this year I wagered a colleague that I could open up the source of the 4.10 kernel (the one that was once current in Ubuntu 16) and find an obvious defect in less than an hour. It actually only took me about 15 minutes, to find a deadlock in the squashfs that was triggered by kmalloc failure and an error path via goto, which of course nobody should ever use. And while I'm reading it I'm just thinking to myself that this is the worst program I've ever seen and it would never pass a code review at my workplace, but it's out there right now running on billions of computers.
Earlier quoted context omitted.
their installer downloaded the game into shared storage. They should at least have known that access to shared storage is not sandboxed and should have been verifying what they are about to install instead of trusting no other app would maliciously place an apk where their installer did expect it to be... ideally they would never have used shared storage at all... that said, the sandboxing and permission system worke…
So you have to trust the app not to do anything stupid or malicious? Isn’t the whole point of an operating systems permission system so you don’t have to trust the developer? All apps having access to shared storage without explicit permission is no better than computer operating systems. If an app can trash your user data the permission system is useless.
I would agree that conflating external storage options with shared storage was a huge mistake which made developers somewhat unaware that this is something that is actually not sandboxed as anything else would have been. But i think nonetheless it is the responsibility of the developer to not just assume how stuff works and in this case it is quite obvious if you actually happen to ask yourself if something like this would be possible. This is especially true if you require novice users to install your app with delicate permissions as the ability to install other apps.
To be clear on this, they made the choice to use shared storage instead of using storage protected by androids sandboxing and permission systems. They probably made this choice without knowing that they are effectively allowing other apps access to files of their installer because shared storage has been conflated with external storage options but mainly because they did not evaluate the options they had and the implications of those carefully enough.
Apparently Android 10 improved this somehow (probably by making filesystem permissions work as usual).
To me, the biggest part of this story is: 1. Over two years ago, this was apparently detected automatically by the syzkaller kernel fuzzer, and automatically reported on its public mailing list. [1] 2. Over a year and a half ago, it was apparently fixed in the upstream kernel. [2] 3. It was apparently never merged back to various "stable" kernels, leading to the recent CVE. [3] So you might read that and think "Ok, p…
Earlier quoted context omitted.
> How many consumers across the world would actually be at risk… We don't know, because we don't know who bought it and how widespread they deployed it.
Oh come on. We can never know with 100% certainty. But they already know the company is selling to authorities, not random people. Can't we make an educated guess here?
Amnesty International has specifically criticized NSO specifically regarding UAE activist Ahmed Mansoor. He is currently serving 10 years in jail. UN human rights experts considered his arrest and imprisonment "a direct attack on the legitimate work of human rights defenders". He was monitored by the UAE using NSO technologies.
Amnesty International have also complained that they have been targeted with NSO Group technology - specifically Pegasus. They're currently launching a legal case in Israel to restrict their export license.
A separate case claims that NSO Group used Pegasus to help the Saudis spy on Khashoggi, who was brutally murdered in the Saudi embassy.
I don't think we need to argue about the bad guys in this case.
Sources: https://www.amnesty.org/en/latest/news/2019/09/nso-spyware-h...
https://www.amnesty.org/en/latest/news/2019/05/israel-amnest...
https://www.nytimes.com/2018/12/02/world/middleeast/saudi-kh...
Earlier quoted context omitted.
My desktop environment doesn't associate data with particular programs. Data is ideally in standard file formats and multiple programs can interact with it. I can see that tying data to a particular program may improve security, but it would also be extremely inconvenient.
>extremely inconvenient. Maybe. I'd argue "extremely". It does suck, for instance, that Discord as a Flatpak can only access a fixed subset of $HOME directories. But it can't scan your machine's processes like ordinary Discord can (to report the game you're playing), which is a privacy gain. The security (and portability) advantages of sandboxing/containerizing apps may outweigh the hassle of the workarounds/memory i…
To me, the biggest part of this story is: 1. Over two years ago, this was apparently detected automatically by the syzkaller kernel fuzzer, and automatically reported on its public mailing list. [1] 2. Over a year and a half ago, it was apparently fixed in the upstream kernel. [2] 3. It was apparently never merged back to various "stable" kernels, leading to the recent CVE. [3] So you might read that and think "Ok, p…
The Linux kernel is a glaring example software malfunction due to its combination of moderate defect density and incredible extent, along with a culture intolerant of competence. People who became subsystem maintainers because they happened to be hanging around a mailing list in the 90s are still gatekeepers of important subsystems despite their now-decades-long records of continuous malfeasance. Patches that demonst…
After the recent disclosures about Apple vulnerabilities, I've seen a lot of (unwarranted, in my opinion) criticism from HN of Project Zero, specifically the accusation of non-Google bias. For those who hold this position, does this affect your stance?
A minor windows exploit is found, and they publish "Windows Exploitation Tricks". An iOS exploit is found and they do a six part "very deep dive into iOS Exploit chains".
Now, they find a bad Android exploit and they don't publish anything.
“It’s advisable that you don’t install apps from non-trustworthy sources, ” Unpopular opinion but this is why I prefer walled garden apple for my family then alternative.
I don't understand people who want to remove choice. Don't want the ability to install apps from untrustworthy sources? Don't enable the option that gives you that ability.
To me, the biggest part of this story is: 1. Over two years ago, this was apparently detected automatically by the syzkaller kernel fuzzer, and automatically reported on its public mailing list. [1] 2. Over a year and a half ago, it was apparently fixed in the upstream kernel. [2] 3. It was apparently never merged back to various "stable" kernels, leading to the recent CVE. [3] So you might read that and think "Ok, p…
So should we be fuzzing the stable branches separately?
- https://syzkaller.appspot.com/linux-4.14 - https://syzkaller.appspot.com/linux-4.19
As far as I know, no one is doing anything with the syzbot bugs against stable kernels directly, since no company using Linux is paying anyone to do it as their job. But some are getting fixed; e.g., some get reported against mainline too, then fixed and backported.