3 ms·

Fun fact: 5/6 years ago, a bunch of Huawei phones came with world readable /dev/fb0 (framebuffer) device files. This made it trivial for any application to rea

Fun fact: 5/6 years ago, a bunch of Huawei phones came with world readable /dev/fb0 (framebuffer) device files. This made it trivial for any application to read the display, totally bypassing any Android screenshot/screen recording API (not that one existed at the time). Some of those devices also had readable /dev/event/input* files, which allowed touchscreen interaction to be monitored.

jbirer 6y ago
Sounds like a good backdoor with plausible deniability ("the dev forgot to restore permissions").
- tsar_bomba 6y ago
  True in principle, while in the real world the devs didn't even inspect perms on those files or changed them deliberately to fix some access control issue without a second thought. Welcome to embedded software, where the product is ready when it passes the functional tests. In related news, I have seen at least two proprietary drivers which allowed userspace libraries to program the hardware without any kernel oversight, incuding things like DMA engines. Pointed it out to one vendor; "yeah, we guess it's not ideal, but you know, details of the hardware is our secret sauce and customers demand no binaries in the kernel because reasons, blah blah". I assume many of those embedded OpenGL implementations may work that way. Anyone with evidence to the contrary?
- rsynnott 6y ago
  I think Hanlon's razor applies. This sort of shoddy work was pretty common in early Android phones, as companies with little software experience adapted to being OS vendors. Here's another similar in concept (though much worse) one from Samsung: https://nvd.nist.gov/vuln/detail/CVE-2012-6422 https://nvd.nist.gov/vuln/detail/CVE-2012-6422
  - exikyut 6y ago
    > The kernel in Samsung Galaxy S2, Galaxy Note 2, MEIZU MX, and possibly other Android devices, when running an Exynos 4210 or 4412 processor, uses weak permissions (0666) for /dev/exynos-mem, which allows attackers to read or write arbitrary physical memory and gain privileges via a crafted application, as demonstrated by ExynosAbuse.

jbirer 6y ago

Sounds like a good backdoor with plausible deniability ("the dev forgot to restore permissions").

tsar_bomba 6y ago
True in principle, while in the real world the devs didn't even inspect perms on those files or changed them deliberately to fix some access control issue without a second thought. Welcome to embedded software, where the product is ready when it passes the functional tests. In related news, I have seen at least two proprietary drivers which allowed userspace libraries to program the hardware without any kernel oversight, incuding things like DMA engines. Pointed it out to one vendor; "yeah, we guess it's not ideal, but you know, details of the hardware is our secret sauce and customers demand no binaries in the kernel because reasons, blah blah". I assume many of those embedded OpenGL implementations may work that way. Anyone with evidence to the contrary?
rsynnott 6y ago
I think Hanlon's razor applies. This sort of shoddy work was pretty common in early Android phones, as companies with little software experience adapted to being OS vendors. Here's another similar in concept (though much worse) one from Samsung: https://nvd.nist.gov/vuln/detail/CVE-2012-6422 https://nvd.nist.gov/vuln/detail/CVE-2012-6422
- exikyut 6y ago
  > The kernel in Samsung Galaxy S2, Galaxy Note 2, MEIZU MX, and possibly other Android devices, when running an Exynos 4210 or 4412 processor, uses weak permissions (0666) for /dev/exynos-mem, which allows attackers to read or write arbitrary physical memory and gain privileges via a crafted application, as demonstrated by ExynosAbuse.