Frustrated dev drops three zero-day vulns affecting Apple iOS 15 | Hacker News Reader

Frustrated dev drops three zero-day vulns affecting Apple iOS 15

theregister.com

187 pointsLinuxBender59 comments

There were a ton of comments about this a few days ago:

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

I am always shocked when I find out how lax security is handled even by parties of whom I thought they would take security very serious.

Did you know that you can bypass the lockscreen on Linux Mint by plugging in an external monitor?

https://github.com/linuxmint/cinnamon/issues/9123

Did you know that when you use Chromium on an up-to-date Debian stable, it has over 100 unpatched security holes?

https://security-tracker.debian.org/tracker/status/release/s...

If you cannot trust Debian - whom can you trust? Any suggestions which distro takes security serious?

> If you cannot trust Debian - whom can you trust?

When did Debian become a model of trustworthiness regarding software security?

We are talking about one of the distributions applying the most patches to its repository for reasons which are often dubious and with little general oversight.

Debian is famous for being run by volunteers but it has always been kind of dodgy. We are talking about the distribution which made it's version of openssl vulnerable by breaking its random generator in order to silence a Valgrind warning.

Eh, OpenSSL was invoking blatantly undefined behaviour. The diff applied by Debian? GCC and Clang are perfectly entitled to behave the same.

But neither GCC nor Clang did and the diff applied by Debian actually triggered the bug without fixing anything. The fact that OpenSSL also happened to be a terrible piece of software doesn't exonerate Debian.

I have to disagree: OpenSSL shares the blunt of the blame. (Whilst saying that, it doesn’t help that both projects are under resourced.) The Debian maintainer contacted upstream about the underlying issue, but received no response. Nor did the patch break any tests.

We've also seen since then just how broken OpenSSL was generally, with Heartbleed. And why did OpenSSL have its own RNG that invoked undefined behaviour, when it could just read from /dev/random?

Moreover, in hindsight, we have a much better understanding of undefined behaviour than we used to. Undefined behaviour is not “occasionally the optimiser might bite you” but “sometimes you'll get (un)lucky in that it’ll appear to work. Don’t do it”.

Foxboron on the Arch team is very serious about security. Check out the Security page on the archwiki for guidance on building your own hardened Arch system.

Debian security support is provided by volunteers (except for the LTS releases), it is a hard job just to track all the known security issues out there, let alone fix the known issues, let alone find all the unknown issues or harden toolchains and packages against unknown issues. If you would like to help improve Debian security support, please get involved.

https://security-tracker.debian.org/tracker/data/report https://www.debian.org/security/audit/ https://www.debian.org/doc/manuals/developers-reference/pkgs... https://wiki.debian.org/Hardening https://wiki.debian.org/Hardening/RepoAndImages https://wiki.debian.org/Hardening/Goals https://www.debian.org/intro/help

"... whom I thought they would take security very serious."

I have always wondered why "tech" companies constantly make statements on their websites such as "We take security very seriously". (Same for privacy.) There is really nothing to back them up. Its just words, no evidence. Of course the companies are all copying each others statements, but perhaps there is some science behind these words, perhaps these statements really do work. Readers actually believe them.

Its like they can make "promises" without ever actually having to deliver anything, and people actually believe they are getting some sort of "deliverable". Occasionally theres a brief "wake-up" call and then their users go back the illusion.

Being "shocked" it seems is short-lived. No doubt the "tech" companies have figured this out. I can remember when people were "shocked" about all the vulnerabilities in Windows. Those days are gone. Now there is no "shock" at all. Its expected.

Reminds me of the reports of internal communications at Facebook that showed how Sandberg and colleagues were seeking to "normalise" data breaches.

X11 screen lockers are not secure at all if you can get them to crash in any way, they revert to showing the full desktop unprotected.

This isn't quite true. There are some X11 screen lockers (maybe only GNOME?) that coordinate with the login manager so that a crash just leads to a restarted login manager.

...but yes, most X11 screen lockers have this flaw.

anyway you can just skim through the altcrtl+Fn buttons untill you find the alternative screen root shell I left logged in.

fwiw TDE implements SAK. Don't know about anyone else.

> Any suggestions how to run a secure Linux machine?

Prevent physical access, install only ssh for external access and run Sshguard. And use Firefox as a browser.

Hmm.. that is not what I meant. Rephrased it to "Any suggestions which distro takes security serious?" now.

Since it seems that Debian has decided to not patch Chromium for months now, how do I know they won't do the same for Firefox at some point? Or any other software in their repos?

I would prefer a distro which promises to keep all software in their repos secure for a certain amount of time. Even if that means having fewer packages than other distros.

If bang up to date software is what matters to you, Debian's the opposite of what you want. Maybe try Arch, which operates a rolling release approach and is well known for following the bleeding edge. FWIW, its firefox [1] and chromium [2] packages are currently at the latest versions and were both published on the day of the upstream release.

[1] https://archlinux.org/packages/extra/x86_64/firefox/ [2] https://archlinux.org/packages/extra/x86_64/chromium/ (latest update was 24th sept, but there was also a 94 version published on 21st, the day of the stable release)

Why don't they keep Chromium up to date like they do with Firefox? Ubuntu (to my knowledge) exempts browsers from their LTS policy because of security fixes being bundled with feature updates.

Good question. Perhaps NixOS, because it allows you to easily compile your own packages (?)

You're just compiling the same broken code.

The idea is that you download the most recent version of the source code of the package.

I'm on Gentoo 15+ years, am familiar with this theory and process.

Its the same problem just at a different point in time. The latest code introduces the latest bugs and security vulnerabilities too.

> Any suggestions which distro takes security serious?

OpenBSD.

On the "base install". OpenBSD's attitude is, if you install insecure 3rd party code, it's on you.

QubesOS, based on Xen hypervisor, provides compartmented security: a hole in an app need not provide access to anything else. You have multiple mostly long-running VMs for different roles. Hardware access is managed in VMs that do not run app code. 16GB RAM is just barely enough, and apps get no access to a GPU. But it's solid and mature. The 4.1 release, due someday, has had a lot of UX attention.

SpectrumOS is an an attempt at lighter-weight security. Based on NixOS, apps run in a minimal, temporary VM spun up just for the app, sub-second, for experience more like Docker than Virtualbox. Still very much under development. Donate to Alyssa Ross on Github to accelerate dev work.

This is the best answer. Qubes OS is really the only practical way to run Linux in a secure manner right now. Its isolation features are not just useful for security, it makes experimentation really easy as one of never has to worry about messing up the installation.

Spectrum may be an option in the future, and I really hope it succeeds.

Fedora Silverblue is becoming interesting as well, especially with "Toolbox" a tool that lets you quickly spin up relatively isolated containers as long-lived development environments, separated from the main OS-installation.

Silverblue has some promise. However, at this point, security is not a consideration. Toolbox is nice, and gives some of the convenience that you get from Qubes, but unfortunately none of the security.

Code running in a toolbox container still has access to the user's home directory, and based on the bug reports on the topic, there are no plans to address this limitation.

> Code running in a toolbox container still has access to the user's home directory, and based on the bug reports on the topic, there are no plans to address this limitation.

I knew it could have access, but damn, I expected that would be optional. That's disappointing.

It's a real shame. With some additional hardening, it could achieve a nice balance between convenience and security.

I should add that QubesOS has the only secure X environment ever. The central VM ("dom0") controls the actual screens and input devices. Each VM runs its own X server, writing to a raw memory buffer. dom0 copies window contents from those buffers to windows on the real screens, and forwards input from events that address a window to (only) the right VM.

SpectrumOS is built around Wayland instead.

Microphone and camera streams are, likewise, forwarded from dom0 to whatever VM you select to receive them, if any. USB gadgets you plug in, similarly, may be operated by the VM of your choice.

https://isopenbsdsecu.re

Slide 43 is worrying.

I'm not surprised that Linux Mint has egregious security issues, the developers are paid nothing to make it and there's basically no corporate incentive to secure it. On the other hand, Apple and Google have quite literally trillions of dollars at their disposal. Their security teams ought to be the largest and most advanced in the world, but they aren't. They're criminally understaffed and have their hands tied by upper management when it comes to accepting help from third-parties like Corellium who actually know what they're doing. Instead, everyone shuts each other out to pretend like they know what they're doing, only to get clowned on when some 13-year-old takes down their homepage with SQL injection.

I'm tired of pretending like security is anything other than theater and optics at this point. You either accept humility and design transparent software, or embrace complexity and let the machine consume you. The business of building software has started shifting to the latter paradigm, and now they're paying the price for it. If we're lucky, we might see a reprieve of the late-80s within the decade, where the internet is saturated with buggy and proprietary servers ripe for the hacking.

    the developers are paid
    nothing to make it

Isn't Mint the second most used Linux distro or so? Shouldn't selling the default search engine alone bring in a boatload of money?

On their blog they say:

    Search engines who do not share the
    income generated by our users, are
    removed from Linux Mint and might
    get their ads blocked.

https://blog.linuxmint.com/?p=1851

>Did you know that when you use Chromium on an up-to-date Debian stable, it has over 100 unpatched security holes?

What do you expect when you use Debian stable? Precisely people choose Debian stable because it gets no updates. (I'm only half kidding)

Thats why Firefox have lts realices

Reminds me of the Windows XP (I think) days where you could bypass the login screen by pressing cancel.

9x. They were single-user and the credentials were only for network access (file shares etc.) The NT series were all multiuser so that didn't work.

Debian can't be held responsible for flaws in Chromium can they? Wouldn't those same issues exist on all distros with the same version of Chromium? Doesn't the distro just package what they can as best they can?

I am confused about your question. Can you elaborate? Distros usually provide patches for known security holes in their repos. Why would one not hold them responsible to do so?

How could Debian be the security gate for literally 1000s of packages?

Chromium is a huge beast of code, should Debian maintainers be debugging and coding patches to various packages?

I think we can't expect the distro to fix the security issues in everything. It's upstream responsibility to handle their own CVE.

Upstream has done that already. Google patched those bugs months ago.

Are we helping Debian get those processed into Bullseye? Or we just barking ideals? We all know FOSS is under staffed and under funded.

Perhaps Google should have one FTE for each major distro to help keep that beast of a codebase up to the standard these threads seem to expect.

It's a heavy burden to place on Debian - and I don't think it's fair to expect them to have eg Chromium and the 10-hundred other packages perfect.

Debian is fscking awesome, they are doing amazing work. Hip Hip Hooray!!

The burden is entirely Debian's choice. They want to mess around backporting fixes. They could just package upstream's releases, but that would break their choice of stability model. The downsides of that choice of model is nobody's fault but their own.

Debian just pulls in upstream updates for Chromium, since it is basically impossible to provide the normal patch backport method of security updates for modern web browsers, including Chromium and Firefox.

Yep. It's other packages that they try to maintain backports (forks) on. Browsers are basically sub-OSes, and very difficult to fork.

The whole maintainer model exists in Debian because Debian tries to do its own maintenance on packages, even if the original developers are unwilling to accept the fix back.

Chromium and Firefox are sort of monster code bases, though, it’s not surprising to me that distros are reluctant to change it in key ways.

No, software developers and package maintainers do. A distro is where it goes all together and normally under a license.

Even licenses are different across packages in a repo, they normally all have a pretty clear wording how much you can hold responsible them for that (hint: no warranty, no fitness for a particular purpose).

Read it before use and think first, e.g. how that software comes to life and is managed / maintained. Debian =/= Apple.

The software developer (Google) patched those bugs months ago.

Not sure what that has to do with licenses.

The license states "Provided AS-IS". There is no right to damn the distributor to not make it not available (and as far as this is Chromium not even the project) - just that.

>he told The Register, "Talking to Apple Product Security is like talking to a brick wall."

>The Register asked Apple to comment, but the brick wall did not respond.

Seems about right.

Very presumptuous of me to say this, but I wonder if the "brick wall" is a non-technical PR type who has been put in the center of many very technical questions, and has realized that his/her boss doesn't yell at him/her if he/she simply doesn't respond very much to external queries.

It can be hard when your job mostly consists of talking to extremely knowledgable people (such as many researchers in this field are) without yourself being at least broadly knowledgable on nearly everything technical.

I don’t understand your point. They are talking about “Apple Product Security”. If the person employed there is as you describe then it’s first of all an outrage that Apple do not hire sufficiently competent people for these types of critical positions, and secondly it does not exonerate this hypothetical person from the duty of escalating and understanding the impact.

https://tenor.com/view/dono-wall-talking-wall-bricks-gif-177...

Unfortunately it doesn't sound like these could be used for jailbreaking. Maybe that's why Apple didn't care so much...

Question: aren't these objects files on the filesystem since MacOS is Unix-based? In other words, have they forgotten to `chmod` them, or are they just plain objects and the checks are high-level abstractions each developer has to implement manually?

Apple's acting more and more like a government, also with their regulated app market.

> Apple is shipping iOS with known bugs

Shocker

This is not about bugs, there will always be bugs. These are security HOLES.

Security holes like letting any app see the name of the current Wi-Fi network?

I didn't know that wasn't the default. I wouldn't really class this as an urgent security hole.

it's working fine for the bottom line and stock price so why should they care more?

Reply on news.ycombinator.com