init Says Yes to Anything
init Says Yes to Anything: Wildcard Property Triggers
In Android, on property:name=value triggers exist so init can react to state changes. The value is supposed to be a sentinel — a specific string that means "do the thing." Honeywell's logger stack declared four of them with a wildcard:
on property:persist.vendor.hsm.kerdynalog.requestcmd=* → hxlogger_kerdynalog (user root) on property:persist.vendor.hsm.ramoops.requestcmd=* → ramoops dump service (root) on property:persist.vendor.hsm.logdumpd.filepath=* → hxlogger_logdumpd (root) on property:persist.vendor.hsm.bootloader.filepath=* → bootloader log copy (root)
What a wildcard trigger means
* doesn't mean "any value is fine." It means there is no check at all — init will run the service for any property value, including one set by any app able to write that property (the HxLogger app itself sets these from XML values, which is exactly how the root RCE chain reaches them). The trigger is supposed to be the gate; the wildcard removes the gate but leaves the guard booth standing.
Impact
- Unvalidated root service execution — the kerdynalog trigger is the final hop of the confirmed root RCE; the others are the same pattern waiting for their own input paths.
- Log pipeline tampering — the logdumpd and bootloader triggers take paths; arbitrary values mean root-driven file copies to attacker-chosen locations.
- Persistence-friendly — persistent properties survive reboot, so a value planted once keeps firing its service on every boot.
The fix is one character wide
* with an exact sentinel value the service checks in-script ([ "$val" = "GO" ] || exit), or better, drop the property-trigger design for these services and use an explicit ctl.start from a validated caller. A trigger that accepts everything is just a remote-shaped door with the lock painted on.frankSx / frankhacks.blogspot.com — part of the CT47 series. The kerdynalog trigger is the landing zone of the HxLogger root RCE write-up; read that one first.
Comments
Post a Comment