Introduce a new mitigation#31
Conversation
|
Still leaves too many opportunities for code execution, not strict enough for Apple. |
BlueCannonBall
left a comment
BlueCannonBall
left a comment
There was a problem hiding this comment.
All of the changes are of sound origin and their author is clearly of sound body, mind, and intention. These changes align very well with well-established Apple policies relating to security.
|
|
Nul-led
left a comment
Nul-led
left a comment
There was a problem hiding this comment.
This is obviously a malicious attempt to undermine Apple's recently changed policies and thus cannot be approved as is.
aaaaaa123456789
left a comment
aaaaaa123456789
left a comment
There was a problem hiding this comment.
This is a clear defense-in-depth mitigation that will prevent future zero-day exploits from compromising users' security and privacy. Implementing policies discovered by previous research projects, this is the kind of revolutionary improvement that should showcase any significant change in security policy.
In a world where not even CPUs can be trusted to be secure, this is exactly what the average layperson needs to keep their system secure without needing the constant assistance of highly-skilled and highly-specialized professionals.
A bold move, but a necessary one, and maybe the one that will even push power users like myself to consider using Apple products as daily drivers. Big thumbs up.
|
You are a legend. |
ivoszbg
left a comment
ivoszbg
left a comment
There was a problem hiding this comment.
There's only one word that can describe this correctly:
Brilliant.
|
Ah yes, that was the word I was looking for. |
xerz-one
left a comment
xerz-one
left a comment
There was a problem hiding this comment.
Exception incorrectly managed. The current implementation of the PR calls the panic procedure, which is a known unsafe function that leads to undefined behavior, as it then proceeds to execute Turing-complete instructions.
I suggest, instead, to make a new PR which completely gets rid of the faulty code. This includes anything which reads or writes into CPU registers, such as the PC or the IR.
$2,000,000 bug bounty for figuring out that 1%! /s LOL |
|
LGTM! |
1 similar comment
|
LGTM! |
olivia-banks
left a comment
olivia-banks
left a comment
There was a problem hiding this comment.
I think the message may be a bit too vague here. What about "malicious code execution prevented"? I feel like this can provide the user with just enough information to let them feel somewhat informed while still being very vague, which is a hallmark of Apple systems.
I also want to bring up that this text won't actually be visible, I think, until after console_init() is called on line 417. Otherwise, it'll just be logged to somewhere that might not even be accessible with a system that is incapable of executing code of much use at all.
|
"malicious code execution prevented" is way too descriptive, I think "legacy execution system has been deprecated" works much better, as it perfectly describes to a user what is going on, and how it can be fixed, just like any other issue on Darwin / macOS. |
|
This is truly a pull request of all time |
This certainly sounds more Apple like. |
| thread_t thread; | ||
| char namep[16]; | ||
|
|
||
| panic("code execution prevented"); |
There was a problem hiding this comment.
Move to below console_setup and replace "code execution prevented" with "legacy execution system has been deprecated." After that I think this should be good to merge.
There was a problem hiding this comment.
I do agree that "legacy execution system has been deprecated." is a better, more descriptive line, and I will update the PR later. However, because this panic call is not the only offender that prints before console_setup, I believe the cleaner and more correct thing to do is to eliminate the problem altogether in a dedicated pull request and commit set rather than shoving a single-instance fix inside an unrelated feature.
20 participants
Hi, I'd like to introduce a new mitigation to the XNU kernel.
Pros:
Cons:
Judging by Apple's recent developments in security, such as APFS seals that completely prevent modification of system files, new code signing policies that are hostile towards indie and open-source developers, and untested overly-strict sandbox profiles that break operating system functionality, I believe this is a welcome change that respects Apple's security-above-all policy.