Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
MaKo
Anmeldungsdatum: 04.12.2021 Beiträge: 7 Wohnort: Flensburg
|
Verfasst am: 24.08.2024, 20:43 Titel: allocate = callocate? |
|
|
Guten Tag,
wenn ich mit allocate Speicher anfordere, ist dieser Bereich dann immer auf Null gesetzt. Dafür sollte doch callocate sein oder?
Ich nutze: FreeBASIC Compiler - Version 1.10.1 (2023-12-24), built for linux-x86_64 (64bit)
Viele Grüße |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4649 Wohnort: ~/
|
Verfasst am: 24.08.2024, 23:40 Titel: |
|
|
Ja, richtig; ALLOCATE initialisiert nicht, CALLOCATE dagegen schon. Sollte es zumindest ...
Unter Windows funktioniert ALLOCATE wie erwartet - die Werte werden nicht auf 0 gesetzt. Unter Linux Debian, fbc 1.09, habe auch ich das von dir beobachtete Verhalten. Vielleicht ein Bug im Linux-fbc? Keine Ahnung; vielleicht wissen sie im internationalen Forum mehr.
(Glücklicherweise nicht so schlimm, da der nicht initialisierte Speicher ja auch zufälligerweise nur die Werte 0 enthalten könnte ) _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
Berkeley
Anmeldungsdatum: 13.05.2024 Beiträge: 55
|
Verfasst am: 25.08.2024, 12:23 Titel: |
|
|
Kann reiner Zufall sein. Beim Einschalten vom PC ist der RAM erst mal voller Nullen. Das ist ja auch das Problem: du gehst davon aus, dass ein Puffer voller Nullen ist, weils "immer" so war. Irgendwann ist er es aber nicht mehr. Es kracht, und du weißt nicht wieso, weil bei jedem neuen Test nichts mehr passiert... Erschwerend kommt hinzu, dass der Speicherinhalt aus Sicherheitsgründen gelöscht werden muss, was vielleicht nicht in jedem Fall gemacht wird.
Du solltest dich einfach nicht darauf verlassen, dass ein Puffer leer ist. Alle Variablen initialisieren bevor man sie benutzt. Punkt. Dass/wenn BASIC es anders macht ist nur für Programmieramateure bzw. schnell hingeschlampte Testprogramme und auch ein großer Sicherheitsvorteil. Aber darauf sollte man sich nicht stützen. |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4649 Wohnort: ~/
|
Verfasst am: 25.08.2024, 13:44 Titel: |
|
|
Einen Zufall würde ich ausschließen, weil ich folgenden Code versucht habe:
Code: | DIM AS UBYTE PTR speicher = ALLOCATE(100)
PRINT speicher
*speicher = 123
DEALLOCATE speicher
speicher = ALLOCATE(100)
PRINT speicher
PRINT *speicher
DEALLOCATE speicher |
Die Adresse war beide Male gleich (was ja nicht selbstverständlich ist), der Speicher dagegen leer - unter Linux wohlgemerkt. Kann höchstens sein, dass das Betriebssystem da selbständig was tut.
Ansonsten stimme ich dir natürlich zu. ALLOCATE reserviert Speicher; was dann darin steht, ist unbestimmt. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
Berkeley
Anmeldungsdatum: 13.05.2024 Beiträge: 55
|
Verfasst am: 25.08.2024, 17:47 Titel: |
|
|
Genau kann man's nicht sagen und wie schon angedeutet könnte es möglicherweise eine Sicherheitsvorkehrung sein. Wenn man bedenkt dass da im RAM eventuell irgendwelche unverschlüsselten Dokumente rumliegen würden...
Wobei: wenn du den Rechner stundenlang mit irgendeinem fetten Computerspiel laufen lässt, kann man ziemlich ausschließen, dass du danach rein zufällig einen komplett genullten Speicherblock mit malloc()/ALLOCATE kriegst, der nicht extra vom Betriebssystem o.ä. überschrieben wurde. |
|
Nach oben |
|
|
dreael Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 2514 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 25.08.2024, 20:16 Titel: |
|
|
Theoretisch müsste ein aktuelles Betriebssystem Speicher (Platte und RAM) beim Freigeben oder neu reservieren mit Nullen o.ä. füllen, sonst wären Dumpster Diving-Angriffe möglich, z.B. kleine Schadsoftware, die einfach nur temporär grosse Speicherblöcke reserviert und diese nach interessanten Inhalten durchscannt und passende Funde an einen C&C-Server sendet.
Von dem her wäre ein Experiment denkbar mit 2 FB-Programme. Ein erstes FB-Programm soll ein riesiger (in der Grösse frei wählbarer) Block RAM reservieren und diesen mit einem String-Muster füllen (reicht ja irgend ein "The quick brown fox jumps over the lazy dog." o.ä.) und sich dann normal beenden.
Ein zweites FB-Programm soll ebenfalls viel Speicher reservieren, dort aber nichts initialiseren, sondern nur scannen. Spätestens wenn das zweite FB-Programm unser "quick brown fox"-Muster fündig wird, dann wäre das Betriebssystem anfällig für Dumpster Diving-Angriffe.
Für beide FB-Programme sinnvollerweise 64-Bit verwenden, um auch mit heutzutage üblichen RAM-Austattungen moderner PCs und Notebooks umgehen zu können. _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
|
MaKo
Anmeldungsdatum: 04.12.2021 Beiträge: 7 Wohnort: Flensburg
|
Verfasst am: 26.08.2024, 12:02 Titel: |
|
|
Hallo,
danke für Eure Expertise und Eure Zeit.
Der guten Ordnung halber:
Ich habe Eure Vorschläge durchgeführt.
Ich habe die Frage im internationalen Forum eingestellt. Bisher gibt es kein Ergebnis.
Ich habe auf einem alten Turion K8 mit 1 GB (Linux 64-Bit) die beiden Programme geschrieben und laufen lassen. Das erste Programm hat 800 MB angefordert und gefüllt. Wenn schon, denn schon.
Anschließend mit dem zweiten Programm 800 MB angefordert und ausgelesen. Alles Nullen.
Scheint also wirklich alles „genullt“ zu werden
Dasselbe Verhalten habe ich übrigens auch bei z. B. „DIM AS UBYTE var = ANY“ festgestellt. Ergibt auch 0. Hierbei bin ich sicher, dass „damals“ unter windows10 (32_bit) Garbage in den Variablen war.
Viele Grüße |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4649 Wohnort: ~/
|
Verfasst am: 26.08.2024, 14:57 Titel: |
|
|
Zitat: | Dasselbe Verhalten habe ich übrigens auch bei z. B. „DIM AS UBYTE var = ANY“ festgestellt. |
Das ist etwas, was ich auch noch bei Gelegenheit testen wollte (hat sich ja jetzt erübrigt ) - das Ergebnis ist ja dann konsistent. Dann ist es ziemlich sicher eine Implementation des Betriebssystems. Windows liefert nach wie vor "irgendwas". _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
MaKo
Anmeldungsdatum: 04.12.2021 Beiträge: 7 Wohnort: Flensburg
|
Verfasst am: 26.08.2024, 15:22 Titel: |
|
|
Again what learned! |
|
Nach oben |
|
|
|