Bug im OS gefunden: Kann den jemand verifizieren?

D

dettus

Mitglied
Thread Starter
Dabei seit
17.01.2024
Beiträge
9
Reaktionspunkte
1
Hallo!

Ich habe einen ZIEMLICH seltsamen Bug im Betriebssystem gefunden.
Und zwar werden Programme gekillt, wenn sie auf .app enden.

ABER NICHT, wenn es symlinks sind.

Zur Illustration habe ich dort unten ein Shellscript geschrieben.
Wenn irgendwer von Euch dumm^H^H^H^Hmutig genug waere das auszufuehren, waere ich ihm/ihr sehr dankbar.

Wenn ihr auch ganz viel "Killed:9" auf der Konsole seht, heisst es, dass der Bug bei Euch auch auftritt.


Code: 
#/bin/zsh

echo "
Hello!
Thank you for taking a look at this problem.
So, to trigger it, you need to

1. open a new terminal window
2. copy and paste the code below into the new window
3. press CTRL+D in that window
4. press CTRL+D in this window

"
echo "-----------------------------[OPEN A NEW TERMINAL WINDOW, COPY THIS TEXT]---"


echo "cd "`pwd`
echo "cat >one.app
#!/bin/zsh
echo works
"
echo "---[DO NOT FORGET THE LAST LINE, AND TO PRESS CTRL+D IN THE OTHER WINDOW]---"
cat >/dev/null


echo "You just created a script, and the name of the script ends with '.app'"
echo "Now, calling this script causes it to be killed IMMEDIATELY!"
chmod 755 one.app
echo "calling one.app"
./one.app

echo
echo "See? And now look what happens when somebody copies it, and changes the"
echo "name so that it ends in two.exe"
cp one.app two.exe
echo "calling two.exe"
./two.exe
echo
echo "So, one.app and two.exe are IDENTICAL, yet, the OS treats them differently."
echo "Seems strange? Wait till you see what happens with Hard Links!"
ln two.exe three.app
echo "calling three.app"
./three.app
echo
echo "And now this"
cp three.app four.exe
./four.exe
ln one.app five.exe
./five.exe
cp five.exe six.app
./six.app


echo
echo "Neat, huh?"
echo "I will erase the .app and .exe files now, so you can run this script again"
rm one.app two.exe three.app four.exe five.exe six.app
echo "I am currently running Darwin 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:18 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6000 arm64"
echo "It is not a problem of the shell script, it also happens with exectuables"
echo "which I compiled with gcc. So there is something else happening!"
echo
echo "Enjoy finding the bug! Personally, I think it is the best part of my job"




Thomas
 
dettus schrieb:
Hallo!

Ich habe einen ZIEMLICH seltsamen Bug im Betriebssystem gefunden.
Und zwar werden Programme gekillt, wenn sie auf .app enden.

…


Thomas
Zum Vergrößern anklicken....
Erst einmal ein herzliches Willkommen bei MU!
Nun aber zu Deinem Beitrag:
Wenn Du mal in den Programme-Ordner gehst und Dir dort die Informationen der einzelnen Programme ansiehst, wirst Du feststellen, dass diese meistens alle mit der Endung „app“ versehen sind. Und zumindest ist es bei mir so, dass, wenn ich diese aufrufe, nicht „gekillt“ werden.
Und über welches Betriebssystem redest Du überhaupt?
 
Du weißt schon das eine .app an sich ein Bundle ist, also Ordner mit bestimmten Inhalt.
Das .app zu nennen macht es nicht zur App.
Wahrscheinlich wird es von launchd beendet weil es malformed ist.
Was sagt denn das Log?
 
  • Gefällt mir
Reaktionen: wegus
oneOeight schrieb:
Du weißt schon das eine .app an sich ein Bundle ist, also Ordner mit bestimmten Inhalt.
Das .app zu nennen macht es nicht zur App.
Wahrscheinlich wird es von launchd beendet weil es malformed ist.
Was sagt denn das Log?
Zum Vergrößern anklicken....
Natuerlich nicht. Ich bin es von anderen Unixen aber gewoehnt, dass ich meine Executables so nennen darf, wie ich es moechte. :)
Und ich bin auch sicher, dass es letzten Monat noch problemlos funktioniert hat.


Wenn launchd die Ursache ist: Kann man dem das abgewoehnen?
Welches log meinst du genau?

(Entschuldige fuer die dummen Fragen, aber normalerweise tauche ich nicht so tief in Betriebssysteme ein)


Oh, und es ist ein M1 pro, mit 14.2.1 Sonoma
 
@oneOeight hat es bereits erklärt und .app und .pkg sind halt reserved words unter OS X. Klar kannst Du Dinge nennen wie Du es willst, Du kannst auch fahren wie Du es willst - mußt nur mit den Konsequenzen leben.
 
  • Gefällt mir
Reaktionen: DoroS und genexx
wegus schrieb:
@oneOeight hat es bereits erklärt und .app und .pkg sind halt reserved words unter OS X.
Zum Vergrößern anklicken....
Einverstanden. Das erklaert aber noch nicht, warum es mit den Links funktioniert.
(Oder warum es bis jetzt lief, aber ploetzlich nicht mehr?)

Und es beantwortet auch nicht meine Frage: KANN DAS JEMAND VERIFIZIEREN.
 
Ich denke, dass ich das hier gefunden habe:

2024-01-17 10:35:13.690648 (pid/10171/com.apple.managedclient.pds.MDM [10181]) <Notice>: exited due to SIGKILL | sent by launchd[1] during teardown of process-scoped services after host exited
2024-01-17 10:35:13.690651 (pid/10171/com.apple.managedclient.pds.MDM [10181]) <Notice>: service state: exited
2024-01-17 10:35:13.690656 (pid/10171/com.apple.managedclient.pds.MDM [10181]) <Notice>: internal event: EXITED, code = 0
2024-01-17 10:35:13.690658 (pid/10171 [mdmclient]) <Notice>: service inactive: com.apple.managedclient.pds.MDM
2024-01-17 10:35:13.690668 (pid/10171/com.apple.managedclient.pds.MDM [10181]) <Notice>: internal event: PETRIFIED, code = 0
2024-01-17 10:35:13.690671 (pid/10171/com.apple.managedclient.pds.MDM [10181]) <Notice>: service state: not running
2024-01-17 10:35:13.690686 (system) <Notice>: removing child: pid/10181

In den launchd.logs
 
Ok, ist wirklich etwas strange das Verhalten:
Code: 
mutti@macstudnmutti ~ % touch test2.app
mutti@macstudnmutti ~ % vi test2.app
mutti@macstudnmutti ~ % chmod +x test2.app
mutti@macstudnmutti ~ % ./test2.app
zsh: killed     ./test2.app
mutti@macstudnmutti ~ % mv test2.app test2.ap
mutti@macstudnmutti ~ % ./test2.ap
test2
mutti@macstudnmutti ~ % mv test2.ap test2.app
mutti@macstudnmutti ~ % ./test2.app
test2

Mit test2.app als
Code: 
#!/bin/sh
echo "test2"

xyz.app ausführen -> geht nicht
umbennenen und ausführen -> geht
wieder in .app umbenennen -> geht plötzlich auch

Ich würde raten, dass da beim ersten Ausführen irgendwelche File-Attribute gesetzt werden?
 
  • Gefällt mir
Reaktionen: dettus
Deine Mudda schrieb:
xyz.app ausführen -> geht nicht
umbennenen und ausführen -> geht
wieder in .app umbenennen -> geht plötzlich auch
Zum Vergrößern anklicken....
hmm... Den Würgaround könnte man im Notfall ins Script einbauen...

Schön geht aber anders...


Ich würde vermutlich auf *.prg oder .appl ausweichen.
-> Das könnte ein bug sein der potenziell wieder kommt....
Wer weiß, was Apple da mit .app in Zukunft noch vor hat.
 
  • Gefällt mir
Reaktionen: dettus
Okay, in einem anderen Forum habe ich das hier gefunden:

Jemand, der das Problem nachvollzogen hat, hat das hier rausgekriegt:
Code: 
ASP: Security policy would not allow process: 31568, /Users/xxx/test/bin/flac.app
 
dettus schrieb:
Jemand, der das Problem nachvollzogen hat, hat das hier rausgekriegt:
Code: 
ASP: Security policy would not allow process: 31568, /Users/xxx/test/bin/flac.app
Zum Vergrößern anklicken....
Lädst du die Binaries irgendwo runter?
Das halt eine Gatekeeper Geschichte.
Obwohl neuere MacOS wohl auch ohne Quarantäne die Binaries auf Signatur prüfen.
Kannst ja mal codesignen und nochmals testen.
 
oneOeight schrieb:
Lädst du die Binaries irgendwo runter?
Zum Vergrößern anklicken....
Nein, die erzeugt er selbst.

Also, nachdem ich Eure Beitraege gelesen habe, bin ich sicher, dass es sich um einen BUG handelt.
Weil:

Das Suffix ".app" ist eine Konvention fuer Applikationen. Technisch ist es durch VERZEICHNISSE geloest, die einen bestimmten Inhalt haben muessen. Das wird gecheckt, wenn da was nicht passt, wird es rausgekegelt. Soweit gut, soweit richtig.

Wir haben jetzt aber zwei Dinge entdeckt:
1. Dieser Sicherheitsmechanismus triggert auch bei DATEIEN mit dem Suffix .app. Das nervt mich. Ist aber persoenliches Pech. Und nicht das Ende der Welt.
2. Ich habe einen Weg gefunden diesen Sicherheitsmechanismus zu umgehen. Das ist nicht gut.
 
  • Gefällt mir
Reaktionen: wegus
dettus schrieb:
2. Ich habe einen Weg gefunden diesen Sicherheitsmechanismus zu umgehen. Das ist nicht gut.
Zum Vergrößern anklicken....
Wenn du meinst das wäre nicht gut, warte mal auf die Antwort von Apple was die dazu sagen.
 
Das liest sich hier nach dem Verhalten von syspolicy_check bzw. syspolicyd:
https://developer.apple.com/forums/thread/706442

Resolving Trusted Execution Problems
https://developer.apple.com/forums/thread/706442

If none of the above resolves your issue, look in the system log for clues as to what’s gone wrong. Some good keywords to search for include:
  • gk, for Gatekeeper
  • xprotect
  • syspolicy, per the syspolicyd man page
  • cmd, for Mach-O load command oddities
  • amfi, for Apple mobile file integrity, per the amfid man page
  • taskgated, see its taskgated man page
  • yara, discussed in Apple Platform Security
  • ProvisioningProfiles
Zum Vergrößern anklicken....
 
Die App-Bundles sind kein Sicherheits-Feature, sondern lediglich ein Bundling-Konzept. Davon gibt es viele in MacOS. Es geht im Grunde nur darum, Ordner samt Inhalt im Finder (oder besser allgemein in den oberen GUI-Schichten) als eine logische Einheit darzustellen. Alle Ordner mit app-Extension werden als ausführbare Anwendung betrachtet. Anstatt, wie in Windows, wie ein Tier in den Ordner gehen zu müssen und zu raten, welche der .exe, .bat, .com – weiß der Geier, was es sonst noch gibt – nun die Anwendung startet, muß man bei einem app-Bundle nur den Ordner "starten" und das System schaut selbst nach, wie die Anwendung gestartet werden soll.

Es gibt noch viele weitere solcher Bundles, die nach einem festgelegten Schema aufgebaut sein müssen und somit dem User als ein Objekt präsentiert werden.

Die Shell weiß im übrigen nichts von den Bundles, wenn man mal von einzelnen Befehlen wie "open" absieht. In der Shell sind es gewöhnliche Ordner.

Aus der Rubrik "Hach… damals…": Dieses Application-Bundle-Konzelt gab es übrigens schon seit 1987 in RiscOS, mit dem Unterschied, daß Application-Bundle-Namen mit einem ! begannen (Dateiextensions gab es in RiscOS nicht).

Zudem hatte es das Konzept von Image-Dateien. Die kann man grob mit DMGs vergleichen. Sie wurden allerdings nicht als Laufwerk gemountet, sondern verhielten sich im Dateibaum "neutral", wenn man sie betrat. Bei einem Doppelklick wurden sie z.B. in der dafür angemeldeten Anwendung geöffnet. Wenn man sie aber mit SHIFT-Doppelklick geöffnet hat, betrat man ein Dateisystem, welcher in-place anstelle des Archiv-Datei eingesetzt wurde. Für das System waren sie ganz normaler Bestandteil des Dateibaumes. Im Normalfall hatte kein Programm bemerkt, daß es auf Dateien im Image zugegriffen hat oder gar daraus gestartet wurde. Eine Anwendung kann aber nachfragen, ob eine Datei ein Dateisystem beinhaltet und sie als einzelne Datei benutzen (Backup-SW z.B.). Das war ein klasse Feature, weil man ZIP-Archive wie komprimierte und ggf. verschlüsselte Ordner benutzen konnte.

Zipster hatte das für macOS nachgebildet. Leider wird es schon seit Jahren nicht mehr gepflegt.

Es gab auch ein ImageFS, was transparent Bilder konvertieren konnte. Es hatte z.B. dafür gesorgt, daß Bilder, die im "falschen" Format vorlagen trotzdem in Anwendungen benutzt werden konnten, indem sie für die jeweilige Anwendung aussahen, als wären sie im "korrekten" Format und wurden beim laden on-the-fly konvertiert. (Damals gab es ja noch jede Menge plattformspezifische Bildformate.)

Hach… damals…
 
  • Gefällt mir
Reaktionen: M001 und herberthuber
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten