Cron- Jobs aanmaken in Magento versnelt de boel in Ubuntu.
luntrus

Je haalt hier een bug aan die in 2004 (!) gemeld en gerepareerd is.

Vertel eens waarom je dit post want het komt nu over als een krampachtige poging om lekker even PHP te bashen.

Niks 2004. Ik zie de uitvoering van dit script op mijn bijgewerkte Debian systeem in de logs verschijnen. Actueel dus! Bij nazoeken wat er achter die Clean php session files meldingen zit kom ik bij bovenstaand script uit en het let's hope commentaar in de source code uit.

Dank luntrus. Niet meer nodig want ik heb php ondertussen gedeïnstalleerd. Er was een bepaalde reden dat ik het had geïnstalleerd maar die kan ik me niet herinneren. Een of ander tooltje van een ontwikkel of backup omgeving had het nodig geloof ik. Nou ja, als ik er niet tegenop loop dan zal het niet erg belangrijk zijn geweest.

@ krakatau & anoniem 12:24

Krakatau kan weleens gelijk hebben. Ik snap de reactie van anoniem:12:24 ook niet zo zeer.

Er is namelijk niet zo veel variatie in bugs en zwakheden (vertragende code), als ieder wel eens wil doen geloven.

Het is meer een herhaling van zetten (thema's), net als in de natuur of de muziek,
een eindeloze herhaling van dezelfde aanvalsthema's met kleine onderlinge aanpassingen over de duur van de tijd.
Na veertien jaar van alles onder ogen krijgen, ga je patronen herkennen. Dat heet dan "relevante kennis" opdoen.

Dus niet zo'n slimme manier om eventuele PHP bashing aan de kaak te stellen. Ik denk ook dat dat niet opzettelijk is gedaan door Krakatau (alhoewel ik weet dat hij PHP niet vertrouwt, om het zachtjes uit te drukken - ik ook niet,
nadat ik herhaaldelijk heb gezien wat een zwakke PHP bibliotheek met Intellitamper op een http site kan blootleggen).

In mijn ervaring blijft PHP gebaseerde CMS een voortdurende zaak van zorg, vooral bij verkeerde instellingen, verouderde of kwetsbare plug-in's of jQuery bibliotheken. Niet extra beveiligen met security headers e.d. Het meeste is F-status, soms D-status veiligheid, waarbij heel wat aanbevelingen horen, om de boel ietewat veiliger te maken. Het onveiligst is Word Press, dan volgt Drupal en Magento (80 tot 60% van de websites, gemaakt met deze content management software is als a priori onveilig te kenmerken!).

Re lees: https://magento.stackexchange.com/questions/58002/do-cron-schedule-table-collects-log-cleaning-status-too

I rest my case,

luntrus

Stelletje bashers... wanneer leren jullie nou eens dat alles lekken heeft?
Maak je website dan in Flash en lees elke week hier op security.nl dat er beveiliginsgaten zijn gedicht.
Nee, echt ik wil jullie code wel eens zien in een andere taal. Zitten ook vast beveiligingsgaten in.

Het probleem is gewoon altijd PEBCAK

/var/lib/php5 1733 owner root, group root Sticky bit op de mappen met RX rechten voor de rest, draaiend onder root.

Het is nu dat waar ik het vaak over heb met een slechte inrichting op het OS.
Een applicatie (middleware) voor het OS zoals PHP moet je isoleren in een container met aparte beheersprocedures en eigen service accounts. Het is wat op het eerste gezicht lastiger maar uiteindelijk veiliger.
Daarboven op kun je gebruikersapplicaties neerzetten. Nee dan heb ik met containerisatie niet over Docker klikker de klik en ik heb het ook net over apt yum rpm klikker de klik.

Krakatau nog bedankt voor dit duidelijke praktijkvoorbeeld hoe iets niet moet.

SELinux is je al een verteld.

Ken ik en ik kan er we mee uit de voeten.
Hier is het kennelijk net php niet ingezet.
De complexiteit om behoorlijke werkende functiescheiding door een hele stack heen goed neer te zetten zou je denk ik vies tegenvallen. Het moet door eenvoudige non ict mensen bij audits wel begrepen kunnen worden.

Denk je dat een big data analist zich hierover druk gaat maken of dat hij snel resultaat uit data wil tonen?

ik zeg BS

een half jaar geleden kende je het niet en je opmerking over php die niet zou SELinuxen laat je ook meteen als nonsence prater ontmaskeren!

je hebt er duidelijk GEEN ervaring mee!

Voor die mensen die wat meer diepgang willen:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/mls

Je gooit wat dingen door elkaar, zo lijkt het.

Ten eerste draait PHP niet als root (anders hadden de rechten op die directory de garbage collector van PHP niet buiten kunnen sluiten en was die cron job helemaal niet nodig geweest). De cron job draait wel als root, maar die gooit alleen wat geëxpireerde bestanden weg en ondersteunt geen gebruikerssessies en verwerkt geen gebruikersinvoer.

Ten tweede staat de laatste 3 van 1733 op write+execute, niet voor read+execute. Omdat het een directory betreft betekent het ontbreken van read access dat er geen directory listing kan worden gemaakt (een gewone user kan dus niet opvragen welke bestanden erin staan) en staat execute niet voor het uitvoeren van een programma maar voor het uitvoeren van een directory search, wat wil zeggen dat een gebruiker die de naam van een bestand weet de directorygegevens van dat bestand kan opvragen (wat nodig is om een bestand te kunnen benaderen). De write-permissie betekent dat elke gebruiker bestanden kan aanmaken, hernoemen en weggooien, maar de sticky bit beperkt de laatste twee acties tot bestanden waar hij al eigenaar van is. Daarmee wordt voorkomen dat mensen of processen die aan bestandsnamen weten te komen met die kennis niet aan het manipuleren kunnen slaan om zo sessies te kapen.

Ten derde lijk je te denken dat de eigenaar van een directory bepalend is voor users waaronder processen draaien. De eigenaar van een executable is bepalend als de setuid of setgid bit is gezet, maar dit is een directory en de sticky bit doet wat anders. De eigenaar van die directory (root) staat volkomen los van de user waar PHP onder draait.

@krakatau,

Jammer, dat het soms weer zo slecht gedocumenteerd is. Is het platform ABI-compatible (het werkt immers onder de meeste ELF-systemen) of moet je wellicht gaan recompilen?

Je kunt gaan voor een LD-preload met setuid of andere linker truc. Is niet zo moeilijk in te kloppen. Vertel SE-Linux om "niets te doen" of "allerlei alarmbellen te laten rinkelen". Implementeer wel zorgvuldig, anders zit je met een kwetsbaarheid voor een LD-preload trojaan met root en dan ben je zeker in de aap gelogeerd, zogezegd. De meningen op "security.stackexchange.com" wijzen nogal 1 richting op m.i.

Ik zou echter bij voorkeur gaan voor "Vanilla" met gebruikmaking van musl libc, dit uit veiligheidsoogpunt.

luntrus

Ik gooi helemaal niets door elkaar, het wordt hier gepost als alles onder root / eigenaar root draaiend.
Dat een sticky bit wat anders op een directory weet ik, daar moest ik achter komen omdat de Linux/Unix architecten en solutionisten verzaakten. De eigenaar van een directory doet er wel degelijk toe haal die others rechten maar eens standaard weg. Je zult verbaasd zijn (of niet) hoeveel er dan overal van alles omvalt.
Wat zou de reden zijn om wel write rechten te geven maar geen read, .... security by obscurity,
Heb je een geisoleerde sandbox waar je de eigenaar van een directory de machtiging geeft om op te schonen dan is er helemaal geen probleem (stick-bit of niet op de directory). Het bijhouden van waar de files staan de grootte etc regel je met rechten op de directory. Je kunt rustig files van andere weggooien in een directory ook hebben die rechten op de betreffende inhoud dat je geheel niets mee zou kunnen. Kijk maar eens hoe /tmp er standaard bij staat.

Doe me een lol werk het eens uit met praktijkvoorbeelden in een iets meer complexe settings dan een enkel bestandje voor een enkele gebruiker. Denk aan meerdere middeware producten met hun eigen services waarop gebruikers in een multitenancy benadering in meerdere rollen aan de slag moeten gaan. (big data bi self service)

https://en.wikipedia.org/wiki/Sticky_bit Let even op wat hier staat:
"When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file."

De owner van een directory kan files weggooien die niet van hem zijn.
Zo kom het ook bij hadoop terug. https://www.cloudera.com/documentation/cdh/5-0-x/CDH5-Security-Guide/cdh5sg_sticky_bit_set.html "HDFS file permissions have support for the sticky bit. The sticky bit can be set on directories, preventing anyone except the superuser, directory owner, or file owner from deleting or moving the files within the directory."

@karma

jij zult verbaasd staan hoe efficient en veilig een profesioneel opgezette en beheerde Linux omgeving is. natuurlijk kan dat ook met een ander pointy-klicky-niet-nader-te-noemen-os-waarbij-de-laatste-tijd-de-updates-rot-zijn, maar als je eerlijk zou kunnen vergelijken zou je merken dat twee goede RHCEers een hele afdeling std beheerders van dat alternatief dat jij de hemel steeds in probeert te prijzen linksom en rechtom in kunnen halen enr rondjes draaien hinkend op een been met een blindoek op. ze zijn wel duurder die RHCEers ja, vooral als ze ook nog eens met een PhD uit de beta hoek komen :).


btw, je zat er met de techniek wederom naast he? oh en vwb SELinux heb je ook alleen maar stoere prietpraat!

@karma je snapt sticky bit nog niet helemaal. niet ZOMAAR iedereen kan ANDERMANS files weggooien zoals je lijkt te stellen. het detail zit em in het puntje WIE er allemaal in een sticky bit gezette directory files kan aanmaken. dat wordt bepaald door settings en privileges van gebruiker op het moment van maken van de directory en de extra acls die kunt zetten:

https://linux.die.net/man/5/acl

Ik geef je de links hoe het werkt. Dat is wat ik in de praktijk ook aangetoond hebt dat het zo werkt.
Dat je dat ontkend is nu net de siituatie waarom linux beheerders de informatieveiligheid zo grondig verstieren.

Wat dan de uitweg voor dit soort beheerders is is om dat andere os aan te bevelen. Heb je de eerder genoemde uitwerking voor een complex aan middleware met daarboven op een complex van gebruikers in meerdere rollen al?

Zo meteen ga je nog beweren dat sudo bedoeld is voor het draaien met root https://www.sudo.ws er staat wel degelijk "or another user".

De hamvraag is: welk serviceaccout ga je gebruiken voor opschonen garbage dan wel logfiles en daar gebruik beter niet de zelfde voor als waar de service zelf mee draait en niet degene waar de service mee geïnstalleerd is. Zo bouw je namelijk containers.

Even de hersens laten knerpen en flink knauwen op de inhoud van zo'n draadje als dit.
Daar valt wat van op te steken en te leren.
Goed dat ik er nooit te oud voor zal worden.

Bedankt jongens, anoniem & krakatau,
ergo - complexe zaken kan je ook eenvoudig aan de IT-man brengen.

Het is immer een kwestie van strikt exact blijven denken en het weten.
Anders is het gokken en ga je de "digitale" mist in.

Eerste en tweede jaars studenten van de Hoge School (T)INF-opleidingen,
zouden hier eens zo af en toe mee moeten lezen,
helpt ze om bepaalde denkpatronen aan te leren.

Kijken wie de volgende keer de meeste veiligheids issues scoort ;)

luntrus

Je link wijst naar de facl al list methodiek een losse extensie die met de facl service samenhangt. Deze heeft de mogelijkheid vaan meerdere groepen/gebruikers en is afgekeken van het ibm/microsoft model.
Ik heb implementaties op het os gezien waar de extra registratie zo kon omvallen. Met de gelijke opzet wordt het beheer soms doorgezet naar AD (windows).

De posix dac rechten zit standaard in het Filesystem zijn daarmee stabieler. De werking van dat sticky bit heb ik zo in de praktijk uitgetest (meerdere accounts) juist om veilige containers te krijgen. Toen ik het snapte kon ik ook de documentatie onderbouwing vinden.
Met hadoop zie je de zelfde constructie als de basis DAC.

Ook hier: de owner van de directory kan alle files weg gooien. De directory owner hoeft niet root te zijn. Waarom zou je.
https://docs.oracle.com/cd/E19683-01/816-4883/secfile-69/index.html

Inderdaad de zelfde soort reactie van dd linux guru's als van jou kant. Je laat het zien in de cli en de ogen worden enkel groot en dd mond maakt geen geluid.
Dus doe aub de handelingen in de praktijk. Dat heb ik wel gedaan. Meten is weten.

Nee, niet alles maar de cron job die sessies opruimt draait onder root. Dat is een wezenlijk onderscheid. De cron job verwijdert sessies door simpelweg te kijken of bestanden een bepaalde tijd niet benaderd zijn en doet verder inhoudelijk helemaal niets met die sessies. De PHP-sessies draaien zelf niet als root.
Nee, dan zou ik totaal niet verbaasd zijn. Nogal wiedes dat de rechten die je instelt een doel en een effect hebben, als dat niet zo was zouden rechten geen functie hebben.
Session-id's zijn random en de filenamen op een prefix na ook. De term security through obscurity slaat niet op alles wat je verborgen houdt (dan zouden privésleutels en wachtwoorden ook onder die noemer vallen) maar op de naïeve gedachte dat je veilig bent als je iets verborgen houdt dat wèl te raden is. Een goede session-id is een forse random waarde die in de praktijk niet te raden is. De sticky bit geeft nog eens extra veiligheid: zelfs als een aanvaller wel een sessie-id te pakken krijgt wordt een mogelijkheid om te manipuleren geblokkeerd.

Natuurlijk zijn er ook andere benaderingen mogelijk. Dat wil niet zeggen dat een andere benadering de enige is die werkt.
Weet je nou opeens weer niet waar die sticky bit voor dient? Die dient om precies dat te blokkeren.
Ik had de man page van chmod al gelezen, dank je. De owner van de directory waar we het nu over hebben is root. Als je een systeem hebt waarop je root niet kan vertrouwen houdt alles op. En nogmaals, niet alles draait als root, zoals je zo hardnekkig lijkt te geloven.

Klinkt omslachtig. Om de werking van de sticky bit te snappen had ik voldoende aan een alinea tekst in een man page. Ik heb ook tests gedaan, maar die dienden voor mij niet om te ontdekken hoe het werkt maar om te bevestigen dat ik de uitleg en de implicaties ervan begrepen had. Die uitleg is niet moeilijk:
Als je dat had gelezen en begrepen had je trouwens deze opmerking niet gemaakt:

Los daarvan: we hadden het eigenlijk de hele tijd over de restricted deletion flag moeten hebben en niet over de sticky bit.

Nee hoor, zo werd het niet gepost. Lees het maar terug. Het gaat - inderdaad - om een directory /var/lib/php5 die met zeer beperkte toegang wordt ingesteld door Debian (dat is alleen maar positief) en een cron-job voor opruiming van sessions files die met root rechten draait.

@ anoniem van 9:34

/var/lib/php5 privilege escalatie -

Is het volgende in SECLinux gemitigeerd? Meestal draait het toch al onder zeer beperkte rechten.

Rond SELinux werken kan een aanvaller met een shell command als
Alhoewel shell file ("0") en directory moeten wel worden veranderd.
De shell is dus wel sterk beperkt, enerzijds door SELinux,
anderzijds wellicht bij voorbeeld via apache etc.

"/usr/bin/dir" zit misschien niet op slot bij SELinux, dus is /usr/bin/dir -al /tmp wellicht mogelijk.

Om uit te proberen door een tester:
Wat betreft de onbekende functies van de crond component? ls -l /var/run/ ?
https://vuldb.com/?id.56958 voor die bug in php 5.3.5
en lees https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1307027

Iedereen als iemand als local user of met toegang tot de socket is gezien.

Info credits: Insidetrust dot com's Ben
Alles ligt dus een stukje gecompliceerder als het op het eerste oog lijkt.

luntrus

Je behandelt wat jij containers noemt als een doel op zich en niet als een middel om een doel te bereiken, en vanuit die gedachte wijs je alles af wat hetzelfde doel op een andere manier bereikt. Er is niets mis met de benadering die jij voorstaat, maar als je de flexibiliteit mist om te accepteren dat er ook andere goede manieren zijn, als je een oplossing afwijst die geleverd wordt door een distro met een bewezen staat van dienst op het gebied van stabiliteit en security, dan wek je bij mij de indruk dat je meningen meer uit dogmatisch denken voortkomen dan uit een vermogen om te beoordelen of iets veilig van opzet is.

De garbage collection waar het hier over gaat heeft geen apart serviceaccount, maar is simpeler dan menig init-script dat ook als root gestart wordt. Dat past niet in jouw voorkeursopzet maar het kan ook geen kwaad omdat de code geen interactie met gebruikers heeft, geen ongecontroleerde invoer verwerkt, alleen bestanden opspoort die een poosje niet benaderd zijn en die verwijdert. Dat proces is geen ongeleid projectiel, het is overzichtelijk en veilig, ook als het als root draait.

Jouw hamvraag is alleen maar een hamvraag als per se jouw voorkeur gevolgd moet worden, niet als het doel om een degelijk systeem op te zetten het eigenlijke criterium is.

Je zegt dat je en de eigenaar van de directory en het opschoot proces onder root draait en tevens dat php onveilig is.
Dan zeg ik geen wonder.

Net zoals bijzit moet je geen default user/password gebruiken omdat get dan werkt. Je moet over goede informatieveiligheid nadenken. Geen root nodig dan weg er mee...

Jij stelde dat alles onder root draait, en daar ging Krakatau's reactie over. Niet netjes om dat te negeren.
Debian had er inderdaad voor kunnen kiezen om hiervoor een aparte user te creëren en die eigendom van de directory te maken. Ze hebben zich ongetwijfeld afgevraagd of dat in dit geval iets toe zou voegen. Als je naar het betreffende script kijkt dan doet het het volgende:
• Het leest PHP5-configuratiedata voor verschillende mogelijke containerprocessen om de directories en timeouts voor sessies te bepalen.
• Het gaat via het /proc-filesysteem na welke sessiebestanden van die processen geopend zijn (dus welke sessies actief zijn) en via de touch-utility werkt het de file modification times voor de open sessiebestanden bij.
• Het verwijderd per proces de sessiebestanden waarvan de modification time ouder dan de voor dat proces geldende sessie timeout is.
Ik zie daar geen interactie met users, geen interacties met processen die met users communiceren, geen netwerkverkeer, geen verwerking van gegevens uit ongecontroleerde bronnen. Er wordt domweg niets gevaarlijks gedaan. Die constatering hoor je ook mee te nemen bij het nadenken over een goede informatieveiligheid. Bij Debian, waar men dat script zelf heeft gemaakt, heeft men kennelijk de afweging gemaakt dat hier geen userid uit de voor system users gedefinieerde reeks (100-999) aan hoefde te worden verspild. Dat zou jouw keuze duidelijk niet zijn, maar het is wel een legitieme keuze.

Dan installeert iemand php5 en gebruikt het bijvoorbeeld met apache2. Moet zo iemand een constructie die bedacht is door Debian, een distro met een robuuste staat van dienst op het gebied van stabiliteit en security, aan de kant gooien en er zelf aan gaan sleutelen? Of moet zo iemand nadenken over informatieveiligheid en beseffen dat hij met dat soort gesleutel het risico loopt zelf bugs en beveiligingslekken te introduceren en ook het risico dat er dingen misgaan als Debian met security-upgrades komt die uitgaan van een andere rechtenstructuur? Ik zou zeggen het laatste. Gebruik het dus zoals het is aangeleverd.

Als iemand ontdekt dat de constructie die Debian hiervoor bedacht heeft een beveiligingslek bevat dan is de juiste weg om te bewandelen een bugmelding, waar de ontdekker een eventuele zelf gemaakte patch of configuratiewijziging aan toe kan voegen. Debian heeft een alert securityteam dat de melding onderzoekt en een upgrade uitbrengt waar iedereen baat bij heeft. Dat is, als je over informatiebeveiliging en beheer nadenkt, verstandiger dan je eigen oplossingen eroverheen gooien omdat je die je bij elke wijziging vanuit de distro mogelijk opnieuw moet aanbrengen en in elk geval opnieuw moet testen.

check de booleans ook eens:

https://mgrepl.fedorapeople.org/man_selinux/Fedora18/httpd.html

er is er eentje die heet 'httpd_tmp_exec'

At anoniem van 15:18

Je kent je distro en hoe er mee om te gaan op je duimpje. Proficiat. Mijn insteek is website beveiligingsanalyse en doe dat al 14 jaar.

Linux is me al heel vroeg bijgebracht en dierbaar, omdat ik Windows NT4 en de kernel te midden van allemaal linux admins kreeg aangeboden.Je kreeg de stof via het Microsoft Opleidingsinstituut destijds, maar met de kritische blik van de linux mensen, die het in ziekenhuisomgevingen, de transportsector e.d. NT4 moesten gaan uitrollen.

De in die dagen opgedane ervaringen met het "in de lucht tillen" van servers vergeet ik mijn hele leven niet meer.
De dikke "tomes" staan nog op mijn bureau.

PHP leerde ik van f.r.a.v.i.a. en andere resource engineers online. Nu loop ik als proctor rond bij IT examens en hou zo voeling met de opleidingsvloer en de ontwikkelingen.

groet van,

luntrus

Ik stelde "14-05-2018, 20:19 door karma4
/var/lib/php5 1733 owner root, group root Sticky bit op de mappen met RX rechten voor de rest, draaiend onder root."
Dat is niet alles waar van alles. Krakatau Heeft een duidelijke mening over PHP, dat mag. Maar als je dit als tekorkoming van PHP ziet is dat niet goed. Hij meld dat het niet goed werkt en daarom verwijderd heeft.

Hier raken we de kern waar alle hacks uit voortkomen. Iemand vind het niet zo relevant en/of belangrijk. Vervolgens wordt het als de facto standaard massaal uitgerold. Totdat ...... Het is dezelfde redenering bij de slechte IOT invullingen die je nu volgt.

Dat is nu net de argumentatie om de leverancier alle vrijheid te bieden tot de foute open installaties te doen en vervolgens weg te kijken als het fout gaat. Ik heb al een paar keer meegemaakt dat we de leverancier tijdens een implementatie tot verandering gedwongen hebben. Vervolgens zie jet het later ook weer terugvallen omdat alles zou goedkoop mogelijk moet informatieveiligheid is een kostenpost.

Ik behandel containers als een doel om informatieveiligheid te bereiken. Met name is de wereld van BI big data is dat zeer problematisch door de starre houding van Linux mensen die denken dat een distro of een leveranciers installatiescript de oplossing is waar het geheel van data en code allemaal goed mee geregeld is. Dus niet.

Voor dat laatste zeker eens, helaas wordt overal over het sticky bit gesproken.
Het eerste is zoals je zegt omslachtig. Ik gaf niet voor niets aan dat de Linux guru's gewoon faalden. Met een vereist compliancy doel (scheiding functies rollen) en gedegen algemene achtergronden moet je er dan zelf in investeren.
De man page gaf een hint daar begin je dan mee hoe het exact werkt is verrassender. Er staat nergens dat je files dan je niet kan lezen of schrijven toch kan weggooien als je maar schrijfrechten op de directory hebt.. Dat is helemaal niet intuïtief. Als je gebruikte tools dan ook nog eens rare dingen doen dan heb je nog wat uit te sluiten op cli manier,

Mooie samenvatting van het begrip - restricted deletion flag / sticky bit - via linux support:

http://blog.serverbuddies.com/restricted-deletion-flag-or-sticky-bit/

luntrus

@luntrus

en die boolean alleen is niet het enige, je moet weten dat httpd (apache) onder de httpd_t context draait en niet zo maar een bash met context shell_exec_t mag draaien van SELinux. Er is dus (ongeacht of /tmp gebruikt wordt in je voorbeeld) ook nog de boolean httpd_builtin_scripting en dan mocht bash (via php) dan wel gestart worden door apache, dan mag apache die bash start en dus onder de httpd_t context draait niet zomaar een socket openen (zie httpd_can_network_connect).

efin, er is veel meer aan de hand in enterprise linux land die voor security minded mensen relevant kan zijn. OSS begint flink voor te lopen op wat zaken en concepten.

denk ook aan installers die mbv OpenSCAP tijdend de installatie controleren en indien kan en nodig is zaken mitigaten volgens een vast gestelde security referentie.

Nee (alweer). Ik schreef dat ik PHP heb verwijderd omdat ik het niet meer nodig had. Niet omdat deze Debian oplossing niet (goed) zou werken!

@anoniem van 22:12

Ben met je eens dat open source, en het door jou hier aangehaalde "security enhanced linux" een geweldige inspiratiebron voor veiliger werken kan zijn. We moeten mensen van diverse platform-achtergronden bij elkaar brengen in plaats van van elkaar te vervreemden of nog erger elkander te gaan verketteren. Ik werp dat verre van me en ben daar zeer fel tegen gekant. In wezen is code code of het nu propriety code is of niet, we willen tenslotte allemaal een veiliger cyberomgeving om in en mee te leven. Misschien ben ik ongeschikt voor flame-wars. Het zij zo.

Waar ik voor ben is niet- restrictief delen van beveiligingskennis. De periode sinds 2001 heeft een hele tegenstroming van "security through obscurity" en ontwrichting van de veiligheid van de algemene cyberstructuur doen ontstaan en het dreigt nog steeds verder te ontsporen. De oorzaken en gevolgen zijn ons allen ondertussen wel genoegzaam bekend, neem ik aan.

Ik ben thuis in/met het wereldje van big av, maak er (zijdelings) deel van uit en moest me echt gaan specialiseren om wat verschil te gaan maken. Daarbij richtte ik me op website beveiliging-issues, javascript error hunting, CMS onveiligheid etc.

Anderen gaan eerder de richting op van qualified malware removal en ik vertel dus mensen, wat er aan websites nog mankeert op veiligheidsgebied (info proliferatie, naamserver issues, dns issues, af te voeren jquery biibliotheken, certificeringszaken, Lucky 13 kwetsbaarheid, cloaking, bad iframes, IDS alerts, security headers, die niet zijn geimplementeerd etc. etc, DOM-XSS sources & sinks.).

PHP ken ik door het ontwerpen van zwakke PHP cfg woordenboek files. Mijn online leermeester f.r.a.v.i.a. (R.I.P. (veel te vroeg overleden)) behandelde dit reeds voor gebruik in Intellitamper etc. PHP heeft nog steeds een eigen niche voor waar het als taal destijds in de eerste plaats is geconstrueerd. Ik heb voor hem toen op zijn site ook nog over zwakke cgi gepubliceerd in verband met zoekopdrachten. Er bestaan verbanden tussen weak PHP & weak cgi.

Ik wilde dit even kwijt, zodat we elkander een beetje beter zouden kunnen begrijpen bij het uitwisselen van relevante kennis. Bedankt nog voor je nuttige bijdragen in deze draad. Blijf veilig zowel online als offline, is de oprechte wens van,

luntrus

Nog een leukertje, voorgesteld PHP_echo file code:


luntrus

@luntrus


kun je even uitleggen wat je code nu moet doen? waar komt $sock vandaan die je tesamen met een gegenereerd php script print bijv?


@karma

je leest dingen die er niet zijn en je snapt er nauwelijks wat van steeds. vind je dat zelf niet vermoeiend?

Als je het spoor terugvolgt citeerde Krakatau's in de bedoelde reactie op deze zin van jou:
Het is wel degelijk waar dat je hebt gesteld alles onder root draait. Het is prima als je dat bij nader inzien toch niet vindt of dat je het eruit had geflapt voor je aan doordachte formuleringen toekwam, maar doe niet of je het niet gesteld hebt terwijl iedereen, inclusief jijzelf, kan zien dat dat wel zo is, dat gedrag maakt het nogal moeilijk met je te communiceren.

Er zit logica achter, en als je die logica snapt is het opeens wel intuïtief. Het vergt de achtergrondkennis dat in POSIX compliant filesystems een bestand door een inode wordt vertegenwoordigd en een directory-entry een verwijzing naar die inode bevat. Dat is basiskennis als je met dat soort systemen niet alleen maar als eindgebruiker omgaat. Elke systeembeheerder hoort te zorgen dat die van die basiskennis op de hoogte is.

Goed, in de inode zijn de attributen van het bestand opgenomen, inclusief de toegangsrechten. Een directory heeft ook een inode die de rechten op de directory bevatten. Omdat dat andere rechten zijn dan die op het bestand kan het inderdaad zo zijn dat je directory-entries mag verwijderen of aanpassen voor bestanden waar je geen lees- of schrijfrechten op hebt. Een directory aanpassen doe je met de rechten die je op die directory hebt en niet met rechten die je op een bestand hebt, die gelden als je de datablokken van het bestand benadert.

Een inode bestaat binnen een filesysteem zolang er referenties aan bestaan. Dat kunnen directory-entries zijn (ik gebruik meervoud omdat het er meerdere kunnen zijn) maar op een gemount filesysteem blijft een inode ook bestaan zolang hij bij een proces in gebruik is. Het is dus het filesysteem zelf dat inodes en de voor een bestand gealloceerde datablokken vrijgeeft, een bestand verwijdert dus, als er geen verwijzingen meer naar zijn en het dus niet meer benaderbaar is. Een gebruiker of proces verwijdert dus feitelijk geen bestanden maar alleen referenties aan bestanden, gebruikmakend van de de toegangsrechten op die referenties.

Als je die achtergrond beheerst is het volkomen logisch wat je ziet gebeuren en is de uitleg over de sticky bit helder zonder dat alle achtergrondinformatie moet worden herhaald.

Je geeft (zoals zo vaak) af op de kwaliteit van Linux en Linuxbeheerders, maar je maakt nu duidelijk dat je eigen kennis te oppervlakkig is om er goed over te kunnen oordelen. Dat is prima, misschien heb je die diepgang ook helemaal nergens voor nodig, en niemand kan alles weten. Maar doe dan alsjeblieft niet alsof je alles wèl beter weet dan ieder ander, dat soort onterechte borstklopperij is arrogant en irritant.

Ik zie posts met beweringen waar de bron niet bestaat of enkelvoudig is zonder echte onderbouwing. Die stellingen met alle onzekerheden worden als zekerheden verkondigd.

Het vermoeiende is dat die zaken in de werkelijke wereld nog geloofd worden ook. Nog erger dat je er persoonlijk last van hebt. Dat is pas echt vermoeiend.

Wil je beweren dat er een goede strategische aanpak rond high privileged accounts en de unprivileged onzin is?
Met je persoonlijke aanval toon je het vermoeiende aan rond een gedegen informatieveiligheid.

@ anoniem van 11:08

Als antwoord op je vraag.

Met deze echo file uit mijn versie van intellitamper (een archaïsche http website file scanner uit 2007, die met aangepaste woordenboeken nog wel te gebruiken is om php configuraties op http-sites vast te stellen) wilde ik aantonen wat voor een gevaar bepaald gebruik van PHP kan inhouden voor de argeloze http website eigenaar/admin/etc.

Niet voor niets dat http als het aan google etc. ligt zo snel mogelijk zal moeten worden uitgefaseerd. HTTPS-Everywhere is hun strategie.

Dit houdt echter niet tegelijk in dat alles over https in de non-public cloud nu allemaal zo veilig gaat verlopen. Voordeel is dat het gemonitor en getrack voor een flink gedeelte uit het oog gehouden wordt en dat is voor bepaalde spelers wel een voordeel bovenop het niet te betwisten veiligheidsaspect (wat niet weet of ziet, wat het product niet deert).

Het grote probleem volgens mij is dat men steeds meer wil laten aflopen op een steeds kwetsbaarder wordende client ten koste van de serverkant. Want vanaf de client-zijde is het digitale goud van heden ten dage te vergaren, namelijk uw en mijn data, waarvan het goed beveiligen een steeds moeilijker klus wordt.

PHP en linux betekent blijvend opletten!

luntrus

dit geeft aan waarom je die code post, niet hoe hij werkt en wat er de exploit / het probleem is.

@ anoniem van 11:43 van vandaag.

Sorry, standaard input en standaard output leeg -

Wat meer verduidelijking, want is een gedeelte van deze command exploit - "remote PHP"

Zie: https://www.exploit-db.com/exploits/25986/

ander gedeelte van de code hier : https://ideone.com/ts0GxX

overeenstemmend met wat ik eerder aangaf, alle variaties op dit thema.

luntrus

tja ik snap je punt nog niet, een dom geconfigureerde apache die /usr/bin/php direct kan aanroepen kan ik niet meteen een php probleem noemen. datzelfde kan ook met een andere bin file gebeuren als je dat zo in apache in stelt toch?

verder zou SELinux dit dus gewoon blokeren ondanks dat apache slecht geconfigureerd zou zijn.