Apache memory error

Ein mögliches Szenario:
Da Shared Memory, wie der Name ja schon sagt, von mehreren Diensten/Programmen gemeinsam genutzt wird, kann es passieren, daß Anwendung A nach Beendigung seiner Arbeit den Speicher nicht ordnungsgemäß löscht und dann Anwendung B die noch im Shared Memory liegenden Daten 'weiterverarbeiten' könnte.

Es lässt sich so gar von einer VM aus Code in einer anderen VM ausführen.
Oder einfach nur der Shared Memory der Nachbar-VM(s) mitlesen und so Daten abgreifen, bis hin zu Keys, Certs, Login-Daten und viele andere empfindliche Daten. Diese Fälle gab es bereits, auch bei mehreren Cloud-Anbietern aus unterschiedlichen Branchen.

Das wird jetzt aber auch zu Off-Topic, daher EOD
 
Es lässt sich so gar von einer VM aus Code in einer anderen VM ausführen.
Oder einfach nur der Shared Memory der Nachbar-VM(s) mitlesen und so Daten abgreifen, bis hin zu Keys, Certs, Login-Daten und viele andere empfindliche Daten. Diese Fälle gab es bereits, auch bei mehreren Cloud-Anbietern aus unterschiedlichen Branchen.

Sind damit zufälligerweise nur VM´s in Form von Container wie z.B. OpenVZ gemeint oder auch VM´s in Form von z.B. KVM-Server?
 
Das ist prinzipiell bei "echten" VMs genauso möglich. Wie real die Theorien des Joe User nun sind, sei mal dahingestellt, wie die meisten komplexeren Angriffe bedarf es hier einer Vielzahl passender Faktoren :)
 
Oder einfach nur der Shared Memory der Nachbar-VM(s) mitlesen und so Daten abgreifen, bis hin zu Keys, Certs, Login-Daten und viele andere empfindliche Daten. Diese Fälle gab es bereits, auch bei mehreren Cloud-Anbietern aus unterschiedlichen Branchen.

Bisher war mir nur bekannt, dass auf jeden Fall bei jeder Virtualisierungstechnologie der Provider auf die VM´s schauen und auch sensible Daten abgreifen kann. Aber dass auch Kunden dies, sofern sie wissen wie es geht, auf VM´s anderer Kunden im ungünstigsten Fall Daten einsehen oder auch abgreifen können, ist mir neu.
 
Wie gesagt: Ich halte dieses Szenario nach bestem Wissen und Gewissen nicht für real. Es mag auch genauso einige funktionierende Exploits geben, um aus einer VM auszubrechen und den Host zu übernehmen. Derartige Werke werden aber kaum genutzt, um eine beliebige VM zu "hacken", sondern finden eher im Bereich hochprofessioneller (Wirtschafts-)Spionage Anwendung. Die Anzahl der Menschen, die solche Exploits besitzen, wird extrem überschaubar sein, und diese Leute möchten damit natürlich auch keinerlei Aufmerksamkeit erzeugen, damit das Geheimnis auch Geheim bleibt.

Man sollte hierbei auch beachten, dass selbst öffentlich bekannte Lücken meistens in der Praxis erstmal nicht "ohne Weiteres" angreifbar sind, dies gilt insbesondere ummittelbar nach der Entdeckung. Natürlich gibt es andererseits durchaus auch richtig üble Sachen wie die diversen OpenSSL-Bugs, wo Dinge wie Heartbleed ohne großen Aufwand ausnutzbar waren.
 
Full-ACK zu den Ausführungen von PHP-Friends.
Aktuell ein leicht komplexes Angriffsszenario, daher derzeit primär nur für professionelle (Wirtschafts-)Spionage interessant, aber eben jederzeit bei jeder Virtualisierungsform/umsetzung real möglich.
Entsprechende HowTos und auch fertige Exploits sind allerdings gegen entsprechendes Cash frei verfügbar.

Nun sollten wir dieses Teilthema dann auch endlich beenden.
 
Der OP nutzt beispielsweise mod_fcgid um PHP einzubinden und somit ist Apache dann der vermeintliche (aber nicht der wahre) Verursacher.

Ein Grund mehr endlich PHP-FPM zu verwenden.

Ich gehe bei mir ganz stark davon aus, dass es an OP und mod_fcgid liegt. Das Limit von shmpages wurde jetzt erstmal erhöht. Wenn das Problem dann noch bleibt werde ich wohl entweder den OP Cache abschalten oder einen Wechsel zu PHP-FPM in Erwägung ziehen.

Ich vermute mal das ich damit eine Problemlösung gefunden habe.

Ich möchte mich auf jeden Fall noch mal bei allen für die Hilfe bedanken:)
 
Back
Top