8 ms·

This again does not work under Android, at least in termux compiled with clang/gcc.

by miduil 4mo ago

ronsor 4mo ago
Android has a lot of hardening and sandboxing that desktop Linux doesn't (and won't for UX reasons).
- miduil 4mo ago
  Yes, it demonstrates that it's possible to harden well - at least for some cases. It appears depending on the environment hardened kernel / runtime environments are pretty much possible to have safeguards working today already.
- deleted 4mo ago
  [deleted]
- __float 4mo ago
  > desktop Linux doesn't (and won't for UX reasons) Can you elaborate?
  - danudey 4mo ago
    Not sure what specifically they're referring to, but Android (and iOS) add a lot of sandboxing to ensure that each application can only access its own files, can't access hardware willy-nilly (bluetooth, scanning wifi, etc), can only link against certain libraries, etc. Imagine if Linux only let you run stuff from Flatpak, and if stuff didn't work in Flatpak then too bad for you. Most Linux users would hate it and it would be a mess a lot of the time, so, for user experience (UX) reasons, they don't do it. Android can get away with it because that's been the app paradigm for decades now.
  - akdev1l 4mo ago
    A very comprehensive SELinux deployment for one. SELinux will stop any process in android from loading kernel modules, that’s not allowed. The android permission model as a whole is ultimately backed by SELinux.
  - lunar_rover 4mo ago
    To solve the issue from the source, you need to enforce security through means like mandatory access control. The problem is that existing desktop and server systems are too mature for that to be practical, you'll have to rework almost everything and users will certainly reject it violently due to the breakages.
    - mike_hearn 4mo ago
      Apple have shown it can be done with macOS. Not only is every app sandboxed in a usefully robust way (even ones distributed outside the app store) but this has been done in a way smooth enough that users didn't revolt.
  - mike_hearn 4mo ago
    Locking down a desktop OS to modern standards really requires what Apple did with macOS, which requires a degree of central coordination that's beyond the Linux community. It mandates huge changes in almost every area of the OS stack, and all apps have to be sandboxed by default out of the box. Developers don't like mandatory sandboxing. It has to be forced on them. So you can see the difficulty of doing it in the open source community, which has for decades now had the worst security of any desktop OS platform (even Windows is better).
- croes 4mo ago
  Android has other problems https://durovscode.com/google-android-security-update-warning-40-percent-devices-unsupported https://durovscode.com/google-android-security-update-warnin...
pjmlp 4mo ago
Because Android is not Linux, as much as some pretend it is. In fact, given the official public APIs, Google could replace the Linux kernel with a BSD, and userspace wouldn't notice, other than rooted devices, and the OEMs themselves baking their Android distro.
- grosswait 4mo ago
  It absolutely is Linux, and yes the JVM could absolutely run on something else. But it is Linux and you can run Linux binaries directly on it - that just isn’t how it is used by end users.
  - pjmlp 4mo ago
    No you cannot, the NDK has a specific set of oficial APIS, and the Android team feels in the right to kill any application that doesn't follow the law of Android land. Some folks like the termux rebels, occasionally find out there is a sherif in town. > As documented in the Android N behavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code can link against at runtime. As a result, if your app uses any private symbols from platform libraries, you will need to update it to either use the public NDK APIs or to include its own copy of those libraries. Some libraries are public: the NDK exposes libandroid, libc, libcamera2ndk, libdl, libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are private, and Android N only allows access to them for platform HALs, system daemons, and the like. If you aren’t sure whether your app uses private libraries, you can immediately check it for warnings on the N Developer Preview. https://android-developers.googleblog.com/2016/06/improving-stability-with-private-cc.html https://android-developers.googleblog.com/2016/06/improving-... These stable APIs, https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis
    - dzaima 4mo ago
      That's specific libraries, when using the default linker. You could construct that same behavior on desktop linux too. And you can avoid it equally well on Android - you can statically-link things just fine, you can use libraries you actually control, and presumably use a custom linker if desired. It's utterly non-surprising that "you run code you don't control" results in "said code...can do arbitrary things for unsupported use". (Never mind that, instead of a "sherif", they could've just renamed all private symbols, or just naturally replaced them over time, breaking your code all the same, just in a more confusing way) Also some obligatory Linux vs GNU/Linux comment. (and it's not like GNU/Linux doesn't ever change under your feet - see the glibc DT_HASH debacle)
staticassertion 4mo ago
I assume because the rxrpc module is not loaded / provided and because unprivileged user namespaces are not allowed, which should be sufficient to mitigate. Curious if someone else has more details though.
jeroenhd 4mo ago
The exploit as posted contains x86 shellcode, so you'd need to drop in the appropriate shellcode to test if it really works. Android wasn't vulnerable the last time, so far it's been a shining beacon of hope for proper SELinux configuration that I wish was more widely available in other places.

This again does not work under Android, at least in termux compiled with clang/gcc.

by miduil 4mo ago

This again does not work under Android, at least in termux compiled with clang/gcc.

ronsor 4mo ago

Android has a lot of hardening and sandboxing that desktop Linux doesn't (and won't for UX reasons).

miduil 4mo ago
Yes, it demonstrates that it's possible to harden well - at least for some cases. It appears depending on the environment hardened kernel / runtime environments are pretty much possible to have safeguards working today already.
deleted 4mo ago
[deleted]
__float 4mo ago
> desktop Linux doesn't (and won't for UX reasons) Can you elaborate?
- danudey 4mo ago
  Not sure what specifically they're referring to, but Android (and iOS) add a lot of sandboxing to ensure that each application can only access its own files, can't access hardware willy-nilly (bluetooth, scanning wifi, etc), can only link against certain libraries, etc. Imagine if Linux only let you run stuff from Flatpak, and if stuff didn't work in Flatpak then too bad for you. Most Linux users would hate it and it would be a mess a lot of the time, so, for user experience (UX) reasons, they don't do it. Android can get away with it because that's been the app paradigm for decades now.
- akdev1l 4mo ago
  A very comprehensive SELinux deployment for one. SELinux will stop any process in android from loading kernel modules, that’s not allowed. The android permission model as a whole is ultimately backed by SELinux.
- lunar_rover 4mo ago
  To solve the issue from the source, you need to enforce security through means like mandatory access control. The problem is that existing desktop and server systems are too mature for that to be practical, you'll have to rework almost everything and users will certainly reject it violently due to the breakages.
  - mike_hearn 4mo ago
    Apple have shown it can be done with macOS. Not only is every app sandboxed in a usefully robust way (even ones distributed outside the app store) but this has been done in a way smooth enough that users didn't revolt.
- mike_hearn 4mo ago
  Locking down a desktop OS to modern standards really requires what Apple did with macOS, which requires a degree of central coordination that's beyond the Linux community. It mandates huge changes in almost every area of the OS stack, and all apps have to be sandboxed by default out of the box. Developers don't like mandatory sandboxing. It has to be forced on them. So you can see the difficulty of doing it in the open source community, which has for decades now had the worst security of any desktop OS platform (even Windows is better).
croes 4mo ago
Android has other problems https://durovscode.com/google-android-security-update-warning-40-percent-devices-unsupported https://durovscode.com/google-android-security-update-warnin...

pjmlp 4mo ago

Because Android is not Linux, as much as some pretend it is. In fact, given the official public APIs, Google could replace the Linux kernel with a BSD, and userspace wouldn't notice, other than rooted devices, and the OEMs themselves baking their Android distro.

grosswait 4mo ago
It absolutely is Linux, and yes the JVM could absolutely run on something else. But it is Linux and you can run Linux binaries directly on it - that just isn’t how it is used by end users.
- pjmlp 4mo ago
  No you cannot, the NDK has a specific set of oficial APIS, and the Android team feels in the right to kill any application that doesn't follow the law of Android land. Some folks like the termux rebels, occasionally find out there is a sherif in town. > As documented in the Android N behavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code can link against at runtime. As a result, if your app uses any private symbols from platform libraries, you will need to update it to either use the public NDK APIs or to include its own copy of those libraries. Some libraries are public: the NDK exposes libandroid, libc, libcamera2ndk, libdl, libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are private, and Android N only allows access to them for platform HALs, system daemons, and the like. If you aren’t sure whether your app uses private libraries, you can immediately check it for warnings on the N Developer Preview. https://android-developers.googleblog.com/2016/06/improving-stability-with-private-cc.html https://android-developers.googleblog.com/2016/06/improving-... These stable APIs, https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis
  - dzaima 4mo ago
    That's specific libraries, when using the default linker. You could construct that same behavior on desktop linux too. And you can avoid it equally well on Android - you can statically-link things just fine, you can use libraries you actually control, and presumably use a custom linker if desired. It's utterly non-surprising that "you run code you don't control" results in "said code...can do arbitrary things for unsupported use". (Never mind that, instead of a "sherif", they could've just renamed all private symbols, or just naturally replaced them over time, breaking your code all the same, just in a more confusing way) Also some obligatory Linux vs GNU/Linux comment. (and it's not like GNU/Linux doesn't ever change under your feet - see the glibc DT_HASH debacle)

staticassertion 4mo ago

I assume because the rxrpc module is not loaded / provided and because unprivileged user namespaces are not allowed, which should be sufficient to mitigate. Curious if someone else has more details though.

jeroenhd 4mo ago

The exploit as posted contains x86 shellcode, so you'd need to drop in the appropriate shellcode to test if it really works. Android wasn't vulnerable the last time, so far it's been a shining beacon of hope for proper SELinux configuration that I wish was more widely available in other places.