[HN Gopher] Defeating KASLR by doing nothing at all
___________________________________________________________________
Defeating KASLR by doing nothing at all
Author : aa_is_op
Score : 93 points
Date : 2025-11-04 10:52 UTC (5 days ago)
(HTM) web link (googleprojectzero.blogspot.com)
(TXT) w3m dump (googleprojectzero.blogspot.com)
| Hendrikto wrote:
| > I reported these two separate issues, lack of linear map
| randomization, and kernel lands at static physical address in
| Pixel, to the Linux kernel team and Google Pixel respectively.
| However both of these issues are considered intended behavior.
| While Pixel may introduce randomized physical kernel load
| addresses at some later point as a feature, there are no
| immediate plans to resolve the lack of randomization of the Linux
| kernel's linear map on arm64.
|
| Funny how Google is paying people to find exploits in their
| product, and also pays people to ignore those vulnerability
| reports.
|
| Pixels seem to be pretty secure when running Graphene, from what
| I have heard.
| londons_explore wrote:
| I'm of the opinion, sadly, that running some custom build of
| android with a few compiler options tweaked away from their
| defaults, is probably far more secure than the latest patched
| versions of iOS or Android.
|
| Yes, it is effectively security by obscurity using the fact
| that nobody knows exactly which compiler options you tweaked,
| but the reality is it works really well since almost all
| exploits need to know some code offsets very precisely to work.
|
| Also, many state security agencies have a ready to go exploit
| for the latest iOS, but they don't have a team ready to
| assemble a custom exploit for your modded android.
| i-con wrote:
| This, having the whole physical memory mapped all the time,
| reminds me of a another issue that was exploitable in KVM
| hypervisors [1]. I wonder what is the reason to have it all
| mapped? Not everybody seems to do it.
|
| [1] https://www.vusec.net/projects/rain/
| nolist_policy wrote:
| The post on lwn.net has some more context in the comments:
|
| https://lwn.net/Articles/1044867/
| fn-mote wrote:
| Edit to add: no need to read the LWN comments, the article is
| crystal clear and to the point - no technical reading skills
| necessary (unlike some very involved Project Zero posts).
|
| - - -
|
| Make sure you get down to the comment by ardbiesheuvel, "linear
| map randomization was already broken", past all the hot air
| about the lack of QA. This comment explains why hot pluggable
| memory causes issues with randomization.
|
| Now off to read the article.
| scott_w wrote:
| I'm a bit confused by your edit and I'm glad I ignored it to
| read the comment you initially highlighted because it does
| offer a strong counter to the Project Zero article.
| stefan_ wrote:
| There are some good points around how limited the entropy
| available here is, but it entirely skips over _who the fuck
| needs hotplug memory in the first place_. That is a very
| niche feature that has no application in the vast majority
| of devices and should never inform the defaults.
| jmalicki wrote:
| It made it very clear - virtualization builds where
| memory can be dynamically added and removed by the
| emulator. I haven't done this with Android but it can be
| quite useful for running lots of test emulators, they can
| adapt their memory to the workload to not overwhelm the
| host.
| rvz wrote:
| Great writeup as always from project zero and this could not
| possibly have been generated by an AI, nor did the author ever
| use an AI to find this very powerful vulnerability.
___________________________________________________________________
(page generated 2025-11-09 23:01 UTC)