Maakte Sigaint ook geen gebruik van SquirrelMail? Zou dit lek dus de reden kunnen zijn dat Sigaint al enige tijd down is?

Waarom draait dat squirelding met die hoge rechten dat zo'n escape kwaad kan. Meerdere verdedingslinies zijn effectiever dan een enkele. De obscurity van enkel code is op de lange termijn nooit veilig.

Gelukkig al tijden geleden van Squirrelmail afgestapt. Moet zeggen dat Roundcube, jaja, ook PHP enzo, toch na de laatste major update aardig m.b.t. de code is opgeschoond.

Eens. Het was meer een vraag waarom dat niet zo ingevuld is als gangbare werkwijze.
Selinux schermt in ieder geval het webserver (proces-gebonden) deel af van de rest op de machine. Het wordt vaak als complex moeilijk dus niet doen afgeserveerd.

Voor de Http apache https://httpd.apache.org/docs/2.4/invoking.html Je kunt de daemon gewoon een eigen service account geven. Dan doe er een eigen container voor dat deel bovenop. (desnoods ngroups als docker toepassen).

Die shellshock werd in ieder geval fraai voor een webserver met selinux dicht gehouden. Ik ha liever gezien dat er geen complete shell voor het doorgeven van web-verkeer (context root naar webserver) gebruikt was maar dat er meer codeerwerk in gestoken was om enkel de parameterstring schoon door te geven gestoken was. Kwestie van veilig ontwerpen en niet bang zijn voor extra werk.

Mooi dat het niet als root staat. Zet de docuroot ook naar een specifiek eigen veilig deel en haalt de grootste angel van path traversal er ook uit. Als je als service account iets gebruikt met zeer veel onnodige rechten lijkt het te veel op root. Zie je te vaak gebeuren omdat het anders veel accounts worden.

Die context switching met de shellshock zit er in omdat poort 80 onder root draait alle poorten onder de 1024 hebben die eigenschap. Het binnenkomend verkeer van de tcpip poort onder root wordt interessant proces doorgegeven aan de http demon niet onder root. Met dat doorgeven van root naar httpd daar zit het gebruik van de Shell.
Met een handige string ging die Shell onder root leuke dingen doen. Met confinement kon hij in ieder geval niet daar buiten komen. Zonder confinement ligt het systeem open.

Dat de sheet leuke onverwachte dingen kon/kan doen kan geen kwaad als het onder de beperkte rechten draait .
Ga eens kijken naar de exec en setenv functies voor forensische spawner processes. Dan zie je dat een complete Shell van root naar beperkt niet noodzakelijk is.

Je zou ook porten kunnen gebruiken die niet aan root vast zitten dan moet er wel een vertaalslag ergens gemaakt worden om de gangbare nummers naar buiten te tonen.

Hi 4amrak ik heb het je duidelijk proberen uit te leggen. Aangezien je het beeld gaf niet thuis te zijn in kernels. Verdiepen in sysinternals van een os en tools is er tegenwoordig niet meer bij. Nope ik niet enkel een windows achtergrond, meer een ander os. Ik geef dus repliek omdat de linux aanhang zoals je zelf beschrijft : snel de fix downloaden en dat is het dan. Heb je naar die c lib functies gekeken? Kennelijk niet

Als het met de shellshock de escap, niet onder root was terechtgekomen dan was er niet zo'n ophef over geweest.
Als de verdere Webserver omgeving veilig was opgezet ook minder. Omdat vele systemen toen zonder de sel versie werkten was de paniek nog groter.
Het verbaast me nog steeds eigenlijk toch niet, dat linux aanhang zo vaak de fout in gaat en vervolgens naar anderen gaat wijzen. Die houding is een probleem voor behoorlijke secùrity invulling.

Duidelijk? Lees zelf dit nog eens:
Wat bedoel je met "die context switching met de shellshock"? De rest van de zin refereert aan het feit dat poorten onder 1024 privileged zijn. Dat is geen eigenschap van shellshock, dat was een bug in bash om code te injecteren, en bash doet op zich zelf niets met HTTP-poorten, daar heb je webservers en dergelijke voor. Niet duidelijk.
De zin loopt tot en met het woord "interessant", maar vanaf "proces" blijkt hij grammaticaal zodanig te ontsporen dat ik geen idee heb wat er staat. Niet duidelijk.
Welk doorgeven van root aan httpd? Hoezo wordt root ergens aan doorgegeven? Bedoel je misschien dat httpd onder root draait en meerdere processen afsplitst die dat niet doen? Suggereer je dat daar shell-code (bash, shellshock) een rol in speelt? Dat klopt niet, hoor. Wederom: niet duidelijk.
Je lijkt inderdaad te denken dat shellshock onder apache gevaarlijk was omdat data uit requests al in bash terechtkomt nog voor het bij processen die met minder rechten draaien terechtkomt. Je kan apache natuurlijk zo configureren dat alles onder root draait, maar dan zit je wel de defaultconfiguratie zoals ik die bij Linux-distro's heb gezien actief om zeep te helpen.

Apache/httpd draait typisch alleen een eerste proces als root. Dat opent logbestanden, opent poorten 80/443 (of andere) om nieuwe verbindingen op te ontvangen, maar handelt die niet zelf af. Het creëert andere processen die die open file descriptors erven, waaronder de TCP-sockets, en die kunnen vervolgens zelfstandig requests die daarop binnenkomen afhandelen. Ze laten echter eerst de root-rechten vallen en draaien onder een user met beperkte rechten die bijvoorbeeld "nobody" of "www-data" heet. Als er (potentieel gevaarlijke) data zelfs maar een proces binnenkomt zijn de root-rechten al niet meer beschikbaar.

Het openen van een listen-socket is niet gevaarlijk, met die handeling ontvangt een proces nog geen data. Dat kan veilig met root-rechten uitgevoerd worden. Zoals gezegd erven afgesplitste processen die open socket, en die gaan pas handelingen doen waarmee data binnen kan komen nadat ze hun rechten hebben verlaagd.

"Met het doorgeven van root naar httpd daar zit het gebruik van de Shell", schreef je. Los van dat er helemaal geen root aan httpd wordt doorgegeven, wat betekent dat überhaupt, komt er bij die hele rechtenverlaging geen shell-code kijken. Pas in de afhandeling van requests met lagere rechten komt mogelijjk bash om de hoek kijken, maar alleen bij verouderde CGI-applicaties of als ontwikkelaars zo naïef zijn om externe programma's via een shell aan te roepen, iets wat altijd te vermijden is.

Nee, Karma, je was niet duidelijk.

Veelal zie je ook dat exploits voor dit soort lekken als eerste een wget of curl opstarten om een fatsoenlijke hoeveelheid
exploit code op te halen en deze dan vervolgens gaan runnen evt zelfs na compileren.
Wat je daar tegen kunt ondernemen:

- zorg in de firewall dat je webserver niet naar buiten kan connecten, zeker niet naar heel internet.
(een uitgaande connect naar poort 25 van je mailserver zal nodig zijn)
- zet geen onnodige software op de webserver, zoals de C compiler, python, perl, wget, curl e.d.
- als dergelijke software nodig is om bijvoorbeeld het systeem te onderhouden of te updaten, zorg dan in ieder geval
dat het account waaronder de webserver draait deze spullen niet kan uitvoeren

Hiermee zorg je in ieder geval dat je de standaard exploits de deur houdt, met weinig moeite.

4amrak dat zijn beide de populistische verhalen over hoe bash reageert met parameters. De kern waarover ik het heb is dat die bash niet in de poort doorgave naar het httpd proces hoort te zitten. Dat is system programming proces manipulatie.
Google eens.
http://www.thegeekstuff.com/2012/03/c-process-control-functions/
https://linux.die.net/man/3/exec Stel dan nog eens de vraag waarom er een complete bash ingezet wordt waar een beperktere set exec/check zou moeten kunnen volstaan.

In jou links lees je toch echt dat de string vanuit de buitenwereld uitgevoerd gaat worden onder root met bash.
Noodzaak om bash daar in te zetten is nada nada. Leg nu eens uit waarom een string vanuit een poort via bash naar de http demon moet. Als je niet zover kunt of durft te gaan ben je enkel een "believer"/volger.

https://www.us-cert.gov/ncas/alerts/TA15-314A Beschrijft wat er speelt duidelijker. Ik houd niet pleisters voor het snel verbergen. zo'n string hoort niet actief in een shell te worden. Het speelt vrij algemeen.