Repository navigation
1.13.0: chain E layout, reliability, and the sweep that was not one - #6
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The private material with the most value, published. Two documents and one transcript, both languages.
CHAIN-E— the FPM arm of the E-OOM primitive, documented at the level of bytes: the write arithmeticT2 = d + 0x110 + 16·N, the six offsets of the fakevar_dtor_entriesbuffer, the requirement that the planted session be exactly 24 bytes in the shapeC|i:<V>;AAAA(and the measured fact thathello|i:<V>;— also 24 bytes — breaks the layout with a SEGV intmp_var), the post-exec ABI desynchronisation that turns every attempt into a 502 unless the payload decouples, and the five paths that did not work, each with the reason it was closed.It is the only published description of hijacking
sapi_module.ub_writerather than a destructor or a session file.LAB ONLY, and now closed from both sides.RELIABILITY— the conditions that decide whether theOff+ ASLR-on chain fires at all: 128M with one worker gives 3/3, 8M gives 0/3, and the failure at 8M is calibration, not the trigger (our older chain goes 8/8 at 8M withdisplay_errors=On). It also settles the sentence that keeps circulating, that loweringmemory_limitdoes not help: true for the mod_php cookie chain where the attacker sizes the body, false as a general claim, because thepure/chain's constants are fixed for the 128M arena. Plus: our own compose does not reproduce the 10/10 becausevuln-8426loads nophp.ini, and cold start is not characterised — 0/3 on a fresh target, 3/3 after a restart.raw/chain-e-aslr-sweep-387.txt— we had a module described as a deterministic ASLR page sweep. It is not one: it sends{"page": N}with no forged body and no address arithmetic, and its success check matched"OK"in the body regardless of any marker. With the code's own criterion it reported success on page 0; with a strict criterion, 387 pages, 387 responses, 0 hits, 0 crashes, no payload ever built.What stayed private, and why. The orchestrator is a fragment that cannot run without our harness, and its forge accepts a
system_addrit never uses. Publishing it as a public chain would mean publishing something that does not run. The session dropper, the C2 and the evasion modules stay where they are. The pilot findings on our own infrastructure are not research material.