Computerbeveiliging - Hoe je bad guys buiten de deur houdt

google "investeerd" in libcurl

24-09-2020, 10:12 door Anoniem, 7 reacties
Goed nieuws voor mensen (zoals ik) die veel (lib)curl gebruiken"

https://daniel.haxx.se/blog/2020/09/23/a-google-grant-for-libcurl-work/

Wat ik wel interessant vond is deze quote uit het artikel:


When security comes up in relation to curl, some people like to mention and propagate for other programming languages, But curl will not be rewritten in another language. Instead we will increase our efforts in writing good C and detecting problems in our code earlier and better.

Jammer (waarom geen rust) of slim (C is wel lekker snel) ?
Reacties (7)
24-09-2020, 10:31 door Anoniem
omdat hip hype en dingetje-du-jour niet matchen met portability stability en uiteindelijk accountability. ik ben blij dat er iemand met gezond verstand en voldoende ervaring bij libcurl zit.


https://www.slideshare.net/bagder/testing-curl-for-security
24-09-2020, 10:32 door [Account Verwijderd]
Het moet natuurlijk google "investeerT" in libcurl zijn. Je weet wel, het is géén voltooid deelwoord.

https://www.jufmelis.nl/werkwoordspelling/voltooid-deelwoord-herkennen/uitleg
24-09-2020, 11:23 door [Account Verwijderd] - Bijgewerkt: 24-09-2020, 11:24
Jammer (waarom geen rust) of slim (C is wel lekker snel) ?

Geloof mij maar dat ze bij Google echt niet zomaar eventjes een programma eruit flansen. Nee, ze hebben zeer waarschijnlijk zeer goed nagedacht over welke programmeertaal ze gebruiken en vervolgens alle best practices toegepast.

Rust heeft alleen maar zin als middel om programma security aan te willen vangen. En verder helemaal niets. Daarom zie je het veel in low level talen maar zaken zoals security van systemen dat vangt Rust helemaal niet op. Daar komt natuurlijk ook nog bij dat Rust een taal is waar de gemiddelde gebruiker toch echt niet op zit te wachten.
24-09-2020, 11:44 door Anoniem
Door donderslag:
Jammer (waarom geen rust) of slim (C is wel lekker snel) ?

Geloof mij maar dat ze bij Google echt niet zomaar eventjes een programma eruit flansen. Nee, ze hebben zeer waarschijnlijk zeer goed nagedacht over welke programmeertaal ze gebruiken en vervolgens alle best practices toegepast.

Rust heeft alleen maar zin als middel om programma security aan te willen vangen. En verder helemaal niets. Daarom zie je het veel in low level talen maar zaken zoals security van systemen dat vangt Rust helemaal niet op. Daar komt natuurlijk ook nog bij dat Rust een taal is waar de gemiddelde gebruiker toch echt niet op zit te wachten.

Google gaat ook niks 'doen' .

Google heeft de lead developer van libcurl een zak(je) met geld gegeven om te besteden aan het verbeteren van security van het programma.
Ik zie niet meteen hoeveel , maar de gelinkte pagina van het patch-grant programma noemt bedragen tussen de $500 en $20.000 .

Rewards for qualifying submissions range from $500 to $20,000. The final amount is always chosen at the discretion of the reward panel and is based on our judgment of the complexity and impact of the patch. The usual reward amounts are:

Up to $20,000 for ideal integration with OSS-Fuzz defined here.
$10,000 for complicated, high-impact improvements that almost certainly prevent major vulnerabilities in the affected code.
$5,000 for moderately complex patches that offer compelling security benefits.
$1,337 for submissions of modest complexity, or for ones that offer fairly speculative gains.
$500 "one-liner special" for trivial improvements that nevertheless have a merit from the security standpoint.

Wat kort door de bocht : dat is maximaal 3 maanden tijd van een goede developer .($20K) .
Daarin ga je niet het hele project kunnen herschrijven .

Daarnaast - een taal is geen wondermiddel - een 'rewrite from scratch' levert gegarandeerd een hele serie nieuwe problemen op. (bekend fenomeen : V1 is een enorm succes, en met de winst gaat men 'V2 'from the ground up' helemaal nieuw schrijven' . En dat loopt uit . en uit . en de klanten lopen weg, want die wilden 'V1+' .)
En in een open source project : ik denk dat het overgrote deel van de bestaande developer community wegloopt als 'het project' besluit om opeens alles in een andere taal te gaan herschrijven.

Als rust-fan's een rustlibcurl willen maken - laat ze dat DOEN.
24-09-2020, 11:49 door [Account Verwijderd] - Bijgewerkt: 24-09-2020, 11:49
https://daniel.haxx.se/blog/2020/09/23/a-google-grant-for-libcurl-work/ More fuzzing. I’ve said it before but let me say it again: fuzzing is really the top method to find problems in curl once we’ve fixed all flaws that the static analyzers we use have pointed out.

Fuzzing is leuk maar toch eigenlijk een zwaktebod. Fuzzing is het achteraf aan de tand voelen van code. Men zou om te beginnen code moeten schrijven - ook met code reviews, unit tests en property-based testing - waarvan men weet dat die veilig is. Zodat fuzzing een formele laatste stap is, waarvan men eigenlijk al weet dat er niets uit zal komen.
24-09-2020, 14:04 door MathFox
Door Toje Fos: Fuzzing is leuk maar toch eigenlijk een zwaktebod. Fuzzing is het achteraf aan de tand voelen van code. Men zou om te beginnen code moeten schrijven - ook met code reviews, unit tests en property-based testing - waarvan men weet dat die veilig is. Zodat fuzzing een formele laatste stap is, waarvan men eigenlijk al weet dat er niets uit zal komen.
In theorie klopt wat jij zegt. In de praktijk begint een Open Source project als een stuk code van een ontwikkelaar dat ook voor anderen nuttig is. Er worden patches met nuttige uitbreidingen ingestuurd; de meest redelijke worden aan het project toegevoegd en dan gaat het echt serieus gebruikt worden.
Er is tot dan nog nooit serieus naar security gekeken... maar je kunt ook niet zomaar vanaf 0 opnieuw beginnen. Vandaar statische checkers en fuzzing.
25-09-2020, 04:52 door [Account Verwijderd]
Door MathFox:
Door Toje Fos: Fuzzing is leuk maar toch eigenlijk een zwaktebod. Fuzzing is het achteraf aan de tand voelen van code. Men zou om te beginnen code moeten schrijven - ook met code reviews, unit tests en property-based testing - waarvan men weet dat die veilig is. Zodat fuzzing een formele laatste stap is, waarvan men eigenlijk al weet dat er niets uit zal komen.
In theorie klopt wat jij zegt. In de praktijk begint een Open Source project als een stuk code van een ontwikkelaar dat ook voor anderen nuttig is. Er worden patches met nuttige uitbreidingen ingestuurd; de meest redelijke worden aan het project toegevoegd en dan gaat het echt serieus gebruikt worden.
Er is tot dan nog nooit serieus naar security gekeken... maar je kunt ook niet zomaar vanaf 0 opnieuw beginnen. Vandaar statische checkers en fuzzing.

Dat is inderdaad wel de de facto situatie met legacy software. Hopelijk niet met nieuwe software. Met name met property based testing kan winst worden geboekt.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.