En uiteraard - typisch Oracle - de mitigerende info achter een login-drempel zetten. Betaal je je blauw aan licentie-kosten, moet je nog veel moeite doen om aan die bedrijfskritische informatie te komen; dit soort kritieke info achter een login-drempel plaatsen laat weer duidelijk zien dat HOrrorcle security nog steeds niet snapt; nog even los van het feit dat de 0-day stiekem al 9 maanden oud is; maar blijkbaar liep Oracle ook te slapen ...

Dat lijkt in eerste instantie het geval, maar is onjuist. Libraries kunnen nou eenmaal functies bevatten die trusted input verwachten, omdat ze anders niet kunnen functioneren en/of te traag zijn.

De kwetsbaarheid hier is dat user-input wordt geïnterpreteerd voordat deze is gevalideerd; tijdens deserialisation kan er al code worden uitgevoerd. M.a.w. wat hier ontbreekt is valideren (UK:sanitisation /US:sanitization) van user input; http://www.ibm.com/developerworks/library/se-lookahead/ beschrijft hoe dit zou kunnen werken.

Het fixen of uitschakelen van de Apache Commons library lost dit ene probleem misschien even op, maar met de schijnwerpers op dit onderwerp verwacht ik meer vergelijkbare lekken in allerlei libraries.

En het gaat hierbij niet alleen om Java, maar om alle user-supplied-input zoals XML (zie bijv. Google: XML XXE) en JSON (zie bijv. https://www.owasp.org/index.php/OWASP_JSON_Sanitizer).

Wat WebLogic mogelijk niet helpt is het volgende, uit http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/:
Meer info:
- Bekijk de (10 maanden oude) slides van Chris Frohoff https://frohoff.github.io/appseccali-marshalling-pickles/
- Apache reactie: https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
- https://jenkins-ci.org/content/mitigating-unauthenticated-remote-code-execution-0-day-jenkins-cli en https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2015-11-11

Wat je zegt is: https://www.owasp.org/index.php/Data_Validation niet juist zou zijn.
Het argument van te traag of niet kunnen werken mag nooit een argument zijn om het dan meer op de verkeerde onveilige manier te doen. Echte security begint als een onderdeel in het fundament/basis. Niet iets wat je achteraf wel bekijkt.

Integendeel, https://www.owasp.org/index.php/Data_Validation#Where_to_include_validation stelt "validation should be performed as per the function of the server executing the code". Leg eens uit wat jij onjuist vindt aan mijn statement?

Helaas, dat kan niet altijd. Bovendien laat het code exploderen - wat ook weer risico's met zich meerbrengt.

Een analogie: je kunt (voor zover ik weet) in bijdragen op dit forum geen Javascript opnemen zodanig dat deze door browsers van lezers wordt uitgevoerd. Echter, als je een account hebt kun je spammen wat je wilt; tekstueel inhoudelijke validatie (moderatie) vindt dan, zonodig, achteraf plaats.
Voor C kenners: strcpy() checkt niet of er buiten een buffer wordt geschreven. Sterker, strcpy() heeft geen flauw benul van buffers en checkt geen geheugenadressen; de functie kopieert gewoon (zo snel mogelijk) bytes vanaf adres 1 naar adres 2 totdat er een nul voorbij komt.

Secure coding best practices zijn in de eerste plaats bedoeld om in alle code, of het nu applicaties of libraries zijn, overal aandacht te hebben voor security. Net als dat er aandacht is voor performance etc. Best practice laat geen ruimte over om de validatie dan maar willekeurig in libraries weg te laten omdat het beter uit komt om security geheel aan de kant te schuiven. Uiteraard kan het beter uitkomen om bijvoorbeeld een security maatregel niet te implementeren, maar dan hoor je er als developer voor te zorgen dat het risico wordt onderkend. Laat er dan ook net heldere documentatie zijn ter waarschuwing dat die C functie zijn dat dit geen user input validation heeft. Een van de redenen voor best practice rules is dat je als gebruiker er vanuit moet kunnen gaan dat je elke willekeurige functie uit een librarie veilig moet kunnen gebruiken. Je stelling dat het onjuist is dat de kwetsbaarheid in de library zit verwerp ik daarom.

Ik probeer jouw quoting te herstellen in mijn reactie:
Jouw "Of" begrijp ik niet helemaal: wat mij betreft moet een ontwikkelaar input valideren (niet alleen om te voorkomen dat untrusted input tot code execution kan leiden). Een ontwikkelaar die niet weet dat je input hoort te valideren is een amateur.

Lastig in dit kader is dat de input zo wordt gemanipuleerd dat, onverwacht door de programmeur, een library wordt gebruikt die toevallig in het classpath staat. Dit type aanval was, voor zover ik weet, tot voor kort vrij onbekend; de ontdekkingen van Chris Frohoff et al. hebben niet de aandacht gekregen die ze verdienden. Echter, ik stel voor dat we er lessen uit trekken en geen tijd verspillen aan de schuldvraag.

Daarnaast heb je natuurlijk gelijk dat het heel handig zou zijn als van library-functies gedocumenteerd zou zijn of ze "veilig" zijn of niet, maar het is natuurlijk wel erg lastig om te documenteren wat een functie allemaal niet doet.

Als programmeur kun je dan ook niet anders dan ervan uitgaan dat, als specifieke functionaliteit (waaronder input validatie) in code van derden niet is gedocumenteerd, deze waarschijnlijk niet aanwezig zal zijn. Vaak is het helemaal niet zo moeilijk om te testen hoe functies reageren op onverwachte input [*] (d.w.z. bewust gemanipuleerde of legitieme doch beschadigde input, maar ook legitieme input uit andere software met een later versienummer dan waarmee wordt getest).

En dat is exact wat programmeurs en testers in veel te veel gevallen nalaten; er wordt alleen getest of iets werkt zoals bedoeld, en niet hoe het systeem zich gedraagt bij onverwachte, eventueel kwaadaardige, input. Voor steeds meer systemen verschijnt fuzzing software; het argument dat er geen tools voor bestaan gaat vaak niet meer op.

[*] probeer in C++ eens strcpy(0,0).

Je hebt gelijk dat ik lekken tussen aanhalingstekens had moeten zetten, want het is op z'n minst discutabel of het hier gaat om een lek in een library (zie ook de, al eerder door mij genoemde, reactie van Apache in https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread).

Zoals het er staat: De validatie moet uitgevoerd worden binnen de api/server waar code uitgevoerd wordt. De validatie hoort niet bij de aanroepende partij/gebruiker te liggen.
Dat de validatie die ontbreekt in de commons library een fout is. Wat voor fout is een ander verhaal. Daar kun je hele boeken over vullen. (software engineering)
Ik was het niet, maar:
Heeft het uitstekend verwoord.


Is dat echt zo of is er meer gebrek aan kennis en ervaring. Eenvoud is het kenmerk van het ware daarom is het ook zo lastig om alles tot de essentie terug te brengen.

Voor C kenners: setenv() geeft een environment-blok als string door. Je kan ook snel een hele shell aanroepen. Op het punt van root (high privileged) naar een meer restricted (web-server) kun je keuzes maken. Veiliger wegens beperktere functionaliteit is setenv() en fork() met meer, makkelijker is shell. Zie hier de shellchock by design.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html

De strcpy staat http://pubs.opengroup.org/onlinepubs/9699919799/functions/strcpy.html#tag_16_571 met als commentaar: "APPLICATION USAGE
- Character movement is performed differently in different implementations. Thus, overlapping moves may yield surprises.
- This version is aligned with the ISO C standard; this does not affect compatibility with XPG3 applications. Reliable error detection by this function was never guaranteed"
Geen betrouwbare errordetectie en verassingen bij implementaties. Daar wil jij een betrouwbaar systeem van maken? Het is peek and poke gedoe met embedded assembler instructies. Je kan het werekend krijgen niet veilig vanuit de basis.

Ik ken het verhaal van de mvc/mvcl 360 assembler instructie. Gedefinieerd als byte voor byte copy van links naar rechts. Dat werd latern als een ontwerpfout gezien. Op het moment dat met 16 32 en 64bit gewerkt werd was dat een vervelend blok aan het been geworden omdat zo veel programmeur van dat links naar rechts per byte gebruikt gemaakt hadden dat ze nooit meer van dat byte/8bit per verwerking af kwamen.


Als je bij acos en atan kijkt zie dat deze wel een goede fout/return beschrijving hebben, Ja zo iets kost overhead en maakt het trager. Daarvoor heb je dan weer aparte func/api's die sneller kunnen zijn in bepaalde situaties. Alles heeft zijn prijs en betrouwbaarheid versus snelheid van uitvoering is er een van.
Wat heeft uw voorkeur veilig maar langzaam of snel en onbetrouwbaar?