Hallo,
hoffentlich kriegst du dann danach keine Crashes.
http://www.pc-magazin.de/common/nws/einemeldung.php?id=56051
gruesse
Klatsch, Fakten, News, Betas 5.087 Themen, 27.849 Beiträge
Xdata Prosseco „Fuer Olaf und Sein MAC OS X“
Da es ein Bs mit Unixstruktur ist, sind solche Meldungen wohl oft übertrieben.
Genau wie mit Linuxviren, wenn es einen ernsthaften gäbe würde dies wie ein Lauf-feuer rumgehen.
So weit ich weiß gibt es bei Mac Os X ähnlich wie bei Ubuntu keinen direkten Root.
Wenn es wegen der alten Programmiesprache c noch erlangen von Root rechten wegen Bufferoverflows gibt,
muß mal eine neue entwickelt werden bei der dies nicht möglich ist.
the_mic Xdata „Fuer Olaf und Sein MAC OS X“
Wenn es wegen der alten Programmiesprache c noch erlangen von Root rechten wegen Bufferoverflows gibt, muß mal eine neue entwickelt werden bei der dies nicht möglich ist.
In Java ist's so gut wie unmöglich, einen Buffer-Overflow zu erzeugen und auszunutzen. Java-Programme schmieren dann einfach mit Out-Of-Bounds-Exception ab.
In Java ist's so gut wie unmöglich, einen Buffer-Overflow zu erzeugen und auszunutzen. Java-Programme schmieren dann einfach mit Out-Of-Bounds-Exception ab.
Olaf19 Prosseco „Fuer Olaf und Sein MAC OS X“
Ich hab mir das Update 10.5.1 gleich gestern draufgenagelt - läuft einwandfrei. Aber danke für den Hinweis :-)
@xdata und mic, was ich immer schon wissen wollte, wieso führt eigentlich ein Buffer Overflow dazu, dass ein Angreifer auf dem silbernen Tablett Root-Rechte serviert bekommt? Warum schmiert das betroffene Programm nicht einfach ab, so wie bei Java? Ist C aus diesem Grund heute keine empfehlenswerte Programmiersprache mehr?
CU
Olaf
Xdata Olaf19 „Danke - ich kann bis jetzt nicht klagen :-)“
Es sollen dadurch zB Speicherauszüge gelesen werden können und zumindest auf Umwegen Rootrechte erlangt werden können.
Wie genau das geht und ob es noch mehr einfallstore durch Überlauf von Speicher, oder Typgrenzen gibt
da kennen sich andere sicher mehr aus.
Das mit c war mal eine Äußerung eines Ada Programmierers bei dem c und seine Nachfolger garnicht gut
wegkahmen. Möglicherweise hat er sich geärgert weil Ada sich nicht so durchgesetzt hat.
Bei Ada gibt es strenge Prüfungen der Typgrenzen hieß es da.
Bei c hört man öfter segmentation fault usw.
Über c weiß ich aber nicht so bescheid :-(
-- Mich stören die kryptischen Zeichen und Steueranweisungen.
Ada hab ich mir mal angeschaut:
Sieht zum Teil wie Pascal oder Oberon aus, nur wohl mit feineren Typ -abtufungen.
Warum Algol nicht in eine Systemsprache modifiziert wurde?
Einige Mainframes sollen mit einem
geänderten Algol programmiert worden sein.
Xdata Nachtrag zu: „Danke - ich kann bis jetzt nicht klagen :-)“
Irgenwie empfinde ich es schon als Bildungslücke nichts mit c oder c++ programmiert zu haben.
Aber wenn man ein "richtiges" c Programm sieht kann einem
richtig schwindelig werden.
Da ist einem ein alte Gfa Basic schon sympatischer;-)
Ruby soll langsam, aber eine sehr klare Scriptspache sein. Mal sehen, wenn die Zeit es mal zuläßt...
Jedenfalls besser als die neumodischen mini Gedächtnistrainer usf.
Olaf19 Xdata „Danke - ich kann bis jetzt nicht klagen :-)“
> Irgenwie empfinde ich es schon als Bildungslücke nichts mit c oder c++ programmiert zu haben.
Mhmm, das ist wieder voll einstein-mäßig relativ - es gibt Menschen, die haben überhaupt noch nie programmiert, weder mit Ada, Basic, C oder sonstwas :-)
1993 habe ich mit C++ angefangen, weil es eine kurze(!) zeitlang so aussah, als würde ich es beruflich gebrauchen können. Leider habe ich seinerzeit schnell wieder die Finger davon gelassen - ich war wohl zu versaut von zu viel Basic! (Omikron am Atari ST).
CU
Olaf
Mhmm, das ist wieder voll einstein-mäßig relativ - es gibt Menschen, die haben überhaupt noch nie programmiert, weder mit Ada, Basic, C oder sonstwas :-)
1993 habe ich mit C++ angefangen, weil es eine kurze(!) zeitlang so aussah, als würde ich es beruflich gebrauchen können. Leider habe ich seinerzeit schnell wieder die Finger davon gelassen - ich war wohl zu versaut von zu viel Basic! (Omikron am Atari ST).
CU
Olaf
Xdata Olaf19 „C und C++... und Programmieren überhaupt ;-)“
Stimmt schon.
Aber spaß gemacht haben sie schon die kleinen eigenen miniProgramme mit Interpretersprachen :-)
Wie beim Physikbaukasten der erste selbstgewickelte Elektromagnet...
Zur "Ehrenrettung" muß man sagen Omikron und Gfa Basic waren ja schon strukturiert, so brauchte man
kaum die verpönten GOTO`s;-)
Meine Schwester hat sich jetzt einen kleinen Weißen Mac Laptop gekauft und überlegt sich neben Macoffice
noch das Mac eigene Office System zu kaufen.
Olaf19 Xdata „Stimmt schon. Aber spaß gemacht haben sie schon die kleinen eigenen...“
Hi xdata, Grüße an die kleine Schwester (oder doch große?) unbekannterweise - ich würde unbedingt empfehlen, NeoOffice anzutesten! Das ist ein 1:1-Clone von OpenOffice, der native unter Mac OS X läuft, während das Original nur über den Umweg des X11-Servers zu benutzen ist. http://neooffice.org
> Zur "Ehrenrettung" muß man sagen Omikron und Gfa Basic waren ja schon strukturiert,
> so brauchte man kaum die verpönten GOTO`s;-)
Vollkommen richtig. Aber hab mal damals versucht, das einem Pascal- oder gar C-Fanatiker beizubringen - Basic taugt nix und fertig, mehr war da nicht zu holen. Ich für meinen Teil kannte den Goto-Befehl nur aus Erzählungen von alten Basic-Dialekten - ich habe ihn nie gebraucht.
Greetz
Olaf
Xdata Olaf19 „Tipp: NeoOffice für Mac OS X rulez!!“
Danke für den Hinweis un den Link.
Meine kleine Schwester ist etwas Jünger als ich.
Sie braucht Das Office Paket eigentlich nur wegen der Kompatibilität für das Psychologiestudiums.
Damit sich Powerpoint Word und Pdf problemlos öffnen bzw bearbeiten läßt.
Olaf19 Xdata „Danke für den Hinweis un den Link. Meine kleine Schwester ist etwas Jünger als...“
Mit Powerpoint bzw. dem OpenOffice-Pendant "Impress" habe ich leider keine Erfahrungen - Worddokumente sollten kein Problem sein, sofern keine allzu exotischen Formatierungen und Tabellen benutzt werden. Ansonsten müsste man evtl. hie und da etwas nacharbeiten.
PDFs bearbeiten kann man afaik mit keinem der angebotenen Office-Pakete! Was unter NeoOffice aber wunderbar möglich ist, das ist das Abspeichern von Office-Dokumenten im PDF-Format. Du kannst dabei außerdem die Komprimierung auf 1% genau einstellen. Da NeoOffice nichts kostet, würde ich es unbedingt ausprobieren - falls es dann doch nicht reicht, kann man immer noch Apple iWork (früher Works) nachkaufen.
CU
Olaf
Xdata Olaf19 „Mit Powerpoint bzw. dem OpenOffice-Pendant Impress habe ich leider keine...“
Sorry,Pdfs sollen nur geöffnet werden.
Danke noch mal für deine Hinweise. Werde ihr empfehlen sich das NeoOffice und iWork mal anzuschaun.
Olaf19 Xdata „Sorry,Pdfs sollen nur geöffnet werden. Danke noch mal für deine Hinweise....“
Will sagen: erst NeoOffice, dann iWork - dann spart deine Schwester ca. 100 €, sollte sich herausstellen, dass iWork ausreicht.
Noch etwas zu den PDFs... die lassen sich sowieso unter jedem beliebigen Betriebssystem öffnen, entweder mit dem Adobe Reader (nicht so schön, weil Bloatware :-() oder mit einem anderen Programm, z.B. "Vorschau" unter Mac OS X oder Foxit-Reader unter Windows... und für Linux gibt es auch etwas.
CU
Olaf
xafford Olaf19 „Danke - ich kann bis jetzt nicht klagen :-)“
... was ich immer schon wissen wollte, wieso führt eigentlich ein Buffer Overflow dazu, dass ein Angreifer auf dem silbernen Tablett Root-Rechte serviert bekommt? Warum schmiert das betroffene Programm nicht einfach ab, so wie bei Java? Ist C aus diesem Grund heute keine empfehlenswerte Programmiersprache mehr?
Das Problem hat erst einmal nur indirekt mit der verwendeten Programmiersprache zu tun, es hat etwas mit der grundlegenden Architektur des PC zu tun, die Daten- und Programmspeicher nur ungenügend trennt. Auf einer solchen Architektur ist es prinzipiell immer möglich einen Overflow auf dem Stack oder dem Heap zu erreichen.
Auch führt ein BO nicht automatisch zu Root-Rechten, er führt nur unter Umständen (aber nicht immer) dazu, dass ein Angreifer eigenen Code ausführen kann. Es kann aber auch einfach nur dazu reichen, ein Programm oder ein System schlicht abstürzen zu lassen.
Da C eine sehr hardwarenahe Programmiersprache ist gelingt es dort recht einfach direkt auf den Speicher zuzugreifen und diesen zu manipulieren. Zudem sind einige Funktionen in C nicht so abgesichert, dass sie Speichergrenzen prüfen und da C vorkompiliert ist gelingt es auch nicht die Speichergrenzen einer Variable zur Laufzeit zu überprüfen. Reserviert man also z.B. Speicher zur Speicherung einer Zeichenkette mit einer Länge von 10 Zeichen und kopiert in diese Benutzereingaben, ohne die Länger dieser Benutzereingaben zu prüfen, so wird ab den 9. Zeichen der Speicherbereich dieses Speichers überschritten (Zeichenketten in C sind Nullbasiert, d.h. ein 0x00 kennzeichnet das Ende der Zeichenkette). Kritisch wird es nun mit dem, was im Speicher überschrieben wird und womit es überschrieben wird.
Im Besten Fall passiert überhaupt nichts, es landet nur in einem im Programmverlauf nicht relevanten Speicherbereich Datenmüll. Ebenso kann es zu einem unvorhersehbaren Programmablauf führen, zu falschen Werten oder einem Programmabsturz. Zufällig und problemlos ist es nicht möglich eigenen Programmcode einzufügen und zur Ausführung zu bringen.
Grundproblem für einen Exploit sind nämlich mehrere Dinge:
Wichtig ist also, dafür zu sorgen, dass der Code vom Aufbau her von der Maschine ausgeführt werden kann, dass er angesprungen wird und was er tut und das Alles erfordert eigentlich weniger Kenntnisse in C oder C++, sondern Kenntnisse der zugrunde liegenden Maschinensprache.
Prinzipiell sind auch Sprachen mit Laufzeitumgebung wie Java, C#, Python oder Scriptsprachen wie PHP nicht vor BOs gefeit, denn liegt das problem in der darunter leigenden Laufzeitumgebung, so lässt sich dieses auch ausnutzen (schön zu sehen z.B. an den BOs in PHP). Allerdings hat es eine Laufzeitumgebung einfacher Speichergrenzen zu überprüfen, da sie sowohl während der Kompilierung des Quellcodes potentielle Schwachstellen erkennen kann, als auch während der Ausführung prüfen kann, was sie hier in welchen Speicherbereich mit welcher Größe kopiert. Tut sie dies an einer Stelle nicht, so kommt es genau wie in anderen Sprachen auch ebenso zu einem Buffer Overflow.
Das Problem hat erst einmal nur indirekt mit der verwendeten Programmiersprache zu tun, es hat etwas mit der grundlegenden Architektur des PC zu tun, die Daten- und Programmspeicher nur ungenügend trennt. Auf einer solchen Architektur ist es prinzipiell immer möglich einen Overflow auf dem Stack oder dem Heap zu erreichen.
Auch führt ein BO nicht automatisch zu Root-Rechten, er führt nur unter Umständen (aber nicht immer) dazu, dass ein Angreifer eigenen Code ausführen kann. Es kann aber auch einfach nur dazu reichen, ein Programm oder ein System schlicht abstürzen zu lassen.
Da C eine sehr hardwarenahe Programmiersprache ist gelingt es dort recht einfach direkt auf den Speicher zuzugreifen und diesen zu manipulieren. Zudem sind einige Funktionen in C nicht so abgesichert, dass sie Speichergrenzen prüfen und da C vorkompiliert ist gelingt es auch nicht die Speichergrenzen einer Variable zur Laufzeit zu überprüfen. Reserviert man also z.B. Speicher zur Speicherung einer Zeichenkette mit einer Länge von 10 Zeichen und kopiert in diese Benutzereingaben, ohne die Länger dieser Benutzereingaben zu prüfen, so wird ab den 9. Zeichen der Speicherbereich dieses Speichers überschritten (Zeichenketten in C sind Nullbasiert, d.h. ein 0x00 kennzeichnet das Ende der Zeichenkette). Kritisch wird es nun mit dem, was im Speicher überschrieben wird und womit es überschrieben wird.
Im Besten Fall passiert überhaupt nichts, es landet nur in einem im Programmverlauf nicht relevanten Speicherbereich Datenmüll. Ebenso kann es zu einem unvorhersehbaren Programmablauf führen, zu falschen Werten oder einem Programmabsturz. Zufällig und problemlos ist es nicht möglich eigenen Programmcode einzufügen und zur Ausführung zu bringen.
Grundproblem für einen Exploit sind nämlich mehrere Dinge:
-
- Der Angreifer weiß primär nicht, wo seine Daten im Speicher liegen werden
-
- Der Angreifer weiß nicht, ob dieser Speicherbereich angesprungen wird und der Code darin zur Ausführung kommt
-
- Er muss Shellcode einfügen, d.h. direkten Maschinencode, sein Code ist also plattformspezifisch
-
- Enthält sein Code 0x00, so muss er den Code so umwandeln, dass er keine 0x00 mehr enthält
-
- Läuft der Code unpreveligiert, so sind seine Möglichkeiten nur beschränkt
-
Wichtig ist also, dafür zu sorgen, dass der Code vom Aufbau her von der Maschine ausgeführt werden kann, dass er angesprungen wird und was er tut und das Alles erfordert eigentlich weniger Kenntnisse in C oder C++, sondern Kenntnisse der zugrunde liegenden Maschinensprache.
Prinzipiell sind auch Sprachen mit Laufzeitumgebung wie Java, C#, Python oder Scriptsprachen wie PHP nicht vor BOs gefeit, denn liegt das problem in der darunter leigenden Laufzeitumgebung, so lässt sich dieses auch ausnutzen (schön zu sehen z.B. an den BOs in PHP). Allerdings hat es eine Laufzeitumgebung einfacher Speichergrenzen zu überprüfen, da sie sowohl während der Kompilierung des Quellcodes potentielle Schwachstellen erkennen kann, als auch während der Ausführung prüfen kann, was sie hier in welchen Speicherbereich mit welcher Größe kopiert. Tut sie dies an einer Stelle nicht, so kommt es genau wie in anderen Sprachen auch ebenso zu einem Buffer Overflow.
Xdata xafford „ Das Problem hat erst einmal nur indirekt mit der verwendeten Programmiersprache...“
So gesehen ist kein Betriebssystem absolut sicher davor. Nichtmal die BSD s
Beim ersten Blaster kam es mir auch so vor wie wenn die --Nt autorität die Xp immer runtergefahren hat auch durch eine Art
Overflow ausgelöst wurde.
Den Wurm selbst hab ich nämlich bei keinem Bekannten oder Kollegen gefunden, die damals vom Blaster betroffen waren.
Bei allen hat das Einschalten der Xp firewall bzw ICF den Blaster aufgehalten, sogar erstmal ohne Patch.
Auf das Tool zum --Windows Dieste abschalten kam ich erst durch den Blaster Wurm.
Olaf19 xafford „ Das Problem hat erst einmal nur indirekt mit der verwendeten Programmiersprache...“
Hallo Xafford, und vielen Dank für deine wie immer sehr sachkundigen Ausführungen!
Wenn man die potenziellen Angreifer bestehenden Hürden so sieht, ist es schon erstaunlich, dass immer noch so viele Rechner angegriffen werden. Insbesondere das direkte Anspringen der Schad-Routine, ohne zu wissen, wo genau diese im Speicher landen wird, stelle ich mir nicht einfach vor. Was die Programmiersprache C angeht, habe ich nach deiner Schilderung das Gefühl, dass weniger die Sprache als solche die Schuld hat, sondern mehr die C-Programmierer. Denn per If-Abfrage wäre es ja möglich zu überprüfen, ob der vom Benutzer eingegebene String länger ist als der dafür reservierte Speicherbereich, bzw. könnte noch während der Eingabe die Einhaltung einer Maximallänge überwacht werden.
Was ich immer wieder verblüffend finde ist, dass sich Menschen mit großem programmiertechnischen Knowhow dazu bereit finden, solchen Schund auf die Menschheit loszulassen - anstatt ihre fachliche Kompetenz konstruktiv einzusetzen... Anwendungsentwickler sind inzwischen doch wieder gefragt?
CU
Olaf
P.S. falls wir uns nicht mehr lesen, wünsche ich schon frohe Feiertage.
xafford Olaf19 „[x] bookmarked... sehr lesenswert!“
Wenn man die potenziellen Angreifer bestehenden Hürden so sieht, ist es schon erstaunlich, dass immer noch so viele Rechner angegriffen werden.
Das mit den Hürden ist relativ. Für mich wären sie unüberwindbar, aber ich kenne mehr als nur eine Person, die dies grundsätzlich mit etwas Zeitaufwand hinbekommen würde.
Insbesondere das direkte Anspringen der Schad-Routine, ohne zu wissen, wo genau diese im Speicher landen wird, stelle ich mir nicht einfach vor.
Ist es auch nicht, aber aus Verständnisgründen (auch was mein eigenes Verständnis angeht) habe ich einiges weggelassen was an programmiertechnischen Kniffen existiert, um dafür zu sorgen den eigenen Code zur Anwendung zu bringen.
Was die Programmiersprache C angeht, habe ich nach deiner Schilderung das Gefühl, dass weniger die Sprache als solche die Schuld hat, sondern mehr die C-Programmierer.
Die Sprache hat insofern Schuld, dass sie es einem Programmierer immens vereinfacht direkt im Speicher herum zu pfuschen, Sprachen ohne Zeigerarithmetik oder Sprachen mit Laufzeitumgebung machen es dem Programmierer eigentlich unmöglich, hier besteht nur der Angriffsvektor der Implementierung.
Nebenbei ist aber auch oftmals der Umgang mit Bibliotheken und Compilern schuld. Es gibt Bibliotheken für C/++, die BOs prinzipiell vermeiden, wer sie jedoch nicht nutzt ist selbst schuld. Zudem neigen viele Programmierer dazu Compiler-Warnungen schlicht zu ignorieren, obwohl diese oftmals auf mögliche Probleme in dieser Richtung hinweisen können.
Denn per If-Abfrage wäre es ja möglich zu überprüfen, ob der vom Benutzer eingegebene String länger ist als der dafür reservierte Speicherbereich
Das geht mit einer IF-Abfrage so nicht, da Eingaben idR Streams darstellen, um diese mit einer IF-Abfrage auf Länge prüfen zu können müsstest Du sie schon in einen Speicherbereich kopiert haben, womit es jedoch geht ist zum einen eine WHILE-Schleife mit einem Längenzähler, oder man nutzt eben passende Bibliotheksfunktionen, bei denen man die zu kopierende Länge entsprechend angibt.
Was ich immer wieder verblüffend finde ist, dass sich Menschen mit großem programmiertechnischen Knowhow dazu bereit finden, solchen Schund auf die Menschheit loszulassen - anstatt ihre fachliche Kompetenz konstruktiv einzusetzen... Anwendungsentwickler sind inzwischen doch wieder gefragt?
Naja, es gibt einen relativ alten und in diesem Bereich sehr richtungsweisenden Artikel auf Phrack namens "Smashing the stack for fun and profit", ich würde den Titel jedoch erweitern zu "Smashing the stack for fun, honour and profit". Mittlerweile ist einfach unheimlich viel Geld zu machen mit "schlüsselfertigen" Exploits.
P.S. falls wir uns nicht mehr lesen, wünsche ich schon frohe Feiertage.
Same to you!
Das mit den Hürden ist relativ. Für mich wären sie unüberwindbar, aber ich kenne mehr als nur eine Person, die dies grundsätzlich mit etwas Zeitaufwand hinbekommen würde.
Insbesondere das direkte Anspringen der Schad-Routine, ohne zu wissen, wo genau diese im Speicher landen wird, stelle ich mir nicht einfach vor.
Ist es auch nicht, aber aus Verständnisgründen (auch was mein eigenes Verständnis angeht) habe ich einiges weggelassen was an programmiertechnischen Kniffen existiert, um dafür zu sorgen den eigenen Code zur Anwendung zu bringen.
Was die Programmiersprache C angeht, habe ich nach deiner Schilderung das Gefühl, dass weniger die Sprache als solche die Schuld hat, sondern mehr die C-Programmierer.
Die Sprache hat insofern Schuld, dass sie es einem Programmierer immens vereinfacht direkt im Speicher herum zu pfuschen, Sprachen ohne Zeigerarithmetik oder Sprachen mit Laufzeitumgebung machen es dem Programmierer eigentlich unmöglich, hier besteht nur der Angriffsvektor der Implementierung.
Nebenbei ist aber auch oftmals der Umgang mit Bibliotheken und Compilern schuld. Es gibt Bibliotheken für C/++, die BOs prinzipiell vermeiden, wer sie jedoch nicht nutzt ist selbst schuld. Zudem neigen viele Programmierer dazu Compiler-Warnungen schlicht zu ignorieren, obwohl diese oftmals auf mögliche Probleme in dieser Richtung hinweisen können.
Denn per If-Abfrage wäre es ja möglich zu überprüfen, ob der vom Benutzer eingegebene String länger ist als der dafür reservierte Speicherbereich
Das geht mit einer IF-Abfrage so nicht, da Eingaben idR Streams darstellen, um diese mit einer IF-Abfrage auf Länge prüfen zu können müsstest Du sie schon in einen Speicherbereich kopiert haben, womit es jedoch geht ist zum einen eine WHILE-Schleife mit einem Längenzähler, oder man nutzt eben passende Bibliotheksfunktionen, bei denen man die zu kopierende Länge entsprechend angibt.
Was ich immer wieder verblüffend finde ist, dass sich Menschen mit großem programmiertechnischen Knowhow dazu bereit finden, solchen Schund auf die Menschheit loszulassen - anstatt ihre fachliche Kompetenz konstruktiv einzusetzen... Anwendungsentwickler sind inzwischen doch wieder gefragt?
Naja, es gibt einen relativ alten und in diesem Bereich sehr richtungsweisenden Artikel auf Phrack namens "Smashing the stack for fun and profit", ich würde den Titel jedoch erweitern zu "Smashing the stack for fun, honour and profit". Mittlerweile ist einfach unheimlich viel Geld zu machen mit "schlüsselfertigen" Exploits.
P.S. falls wir uns nicht mehr lesen, wünsche ich schon frohe Feiertage.
Same to you!
