De kernbeveiliging van Bitcoin is het belangrijkste probleem

Bitcoin Core is de basis van een netwerk dat meer dan 2 biljoen dollar aan waarde veiligstelt. Er staat veel op het spel en veel delen van de codebasis kunnen ernstige bugs bevatten. Er bestaan ​​beveiligingsproblemen op gebieden als de peer-to-peer berichtverwerking (p2p), cryptografische bibliotheken en de consensus-engine. Deze kunnen leiden tot diefstal, het stilleggen van het netwerk of het vernietigen van vertrouwen. Bitcoin is niet zoals traditionele financiële software met verzekeringen of juridische verhaalsmogelijkheden. De veiligheid ervan hangt volledig af van de kwaliteit van de code en de processen om deze te onderhouden.

De beveiligingsaanpak van Bitcoin Core is niet formeel gedefinieerd. In plaats daarvan is het in de loop van de tijd geëvolueerd. De beoordelingsprocessen zijn gedetailleerder, de testinfrastructuur is uitgebreider en als project zijn we voorzichtiger en weloverwogener geweest bij onze softwarewijzigingen. Een langzamer tempo verkleint de kans dat er nieuwe bugs worden geïntroduceerd door overhaaste veranderingen.

Het artikel onderzoekt de veiligheid van Bitcoin Core vanuit verschillende invalshoeken:

• Het openbaarmakingsbeleid is de procedure voor het omgaan met ontdekte kwetsbaarheden
• Het uitgebreide fuzzing-netwerk dat op bugs jaagt
• Een bredere reeks testtools die problemen opspoort en oplost voordat ze in productie gaan

Het betreft niet één enkele strategie, maar eerder complementaire verdedigingsmechanismen die in de loop van de tijd zijn ontwikkeld naarmate het project zich ontwikkelde.

Kwetsbaarheid Informatie openbaarmakingsproces

Bitcoin Core is een project dat geen automatische updates voor software biedt. Dit beschermt zijn gebruikers tegen zijn ontwikkelaars. Alle vrijgegeven binaire bestanden worden vergeleken met de broncode die is gepubliceerd door reproduceerbare builds. De Node Runners zijn verantwoordelijk voor het bepalen welke softwareversie moet worden gebruikt en wanneer deze moet worden bijgewerkt. Dit vormt een probleem in de context van beveiligingsfouten. Het is belangrijk om de oplossingen beschikbaar te hebben als open source voor het beoordelings- en releaseproces, terwijl ook de volledige openbaarmaking wordt uitgesteld om gebruikers de tijd te geven om te updaten.

In het verleden was de publieke bekendmaking per project van kritieke beveiligingsproblemen ontoereikend, ongeacht of deze van buitenaf werden gerapporteerd of door gebruikers werden gevonden. Veel gebruikers waren van mening dat Bitcoin Core geen bugs bevatte. Dit was een zeer gevaarlijke en onjuiste perceptie. Gemotiveerd door deze problemen heeft het project ongeveer anderhalf jaar geleden de aanpak van veiligheidsproblemen herzien, geformaliseerd en verbeterd. openbaarmakingsbeleid Het adviesproces. Het was een doel om de transparantie te vergroten, om de verwachtingen duidelijk te stellen voor beveiligingsonderzoekers, om hen beter te informeren over de gevaren van verouderde software, om effectiever te communiceren over de risico’s van het gebruik ervan, en om de beveiligingsbug beschikbaar te maken nadat deze is onthuld, zodat anderen hiervan kunnen leren en toekomstige kwetsbaarheden kunnen vermijden.

Beleid

All vulnerabilities should be reported to security@bitcoincore.org (see SECURITY.md for details). Each vulnerability that is reported will receive a severity rating. There are four different types of vulnerability:

CriticalBugs which threaten fundamental integrity and security in the Bitcoin network. This is a bug that allows coin thefts at the protocol-level, creation of coins beyond the schedule specified, or permanent network-wide chains splits.

High QualityBugs which have an impact of a large scale on nodes and the network. The bugs can be exploited remotely and cause widespread damage.

MediumBugs with a noticeable impact on the performance or functionality of a node or network, yet limited in scope. Some of these bugs require specific conditions in order to be triggered, for example, non-default setting, or they may result in a service degradation, rather than complete node failure.

Low-costBugs which are difficult to exploit, or that have only a small impact on the operation of a node. These bugs may only trigger under certain non-default settings or via the local network and they do not present an immediate threat.

Low-cost Two weeks will pass after a fix has been released in a major release. Medium You can also find out more about the following: High Quality The severity of the vulnerability will be revealed 2 weeks after End of Life for the latest affected version (roughly one year after a first major release containing the patch was released).

The details on a security vulnerability will not be released until two weeks after the pre-announcement. Pre-announcements will be made two weeks prior to the actual release. They contain details of all the vulnerabilities that have been fixed and the severity of each one.

Critical As they are likely to require an ad hoc procedure, bugs do not fall under the policy. Bugs may also not be a security vulnerability. A reported problem may be deemed serious but not warrant an embargo.

Het team van Bitcoin Core verifieert elke gerapporteerde kwetsbaarheid voordat deze kan worden gebruikt. “Beveiligingsteam” Het project categoriseert kwetsbaarheden in vier ernstniveaus: Kritiek (bedreigingen voor de netwerkintegriteit zoals muntdiefstal of inflatie), Hoog (aanzienlijke impact, op afstand exploiteerbaar), Medium (prestatievermindering of beperkte reikwijdte) en Laag (moeilijk te exploiteren met kleine impact). Het project verdeelt de ernst van de kwetsbaarheid in vier categorieën: kritiek (bedreigingen voor de netwerkintegriteit zoals muntdiefstal en inflatie), hoog (aanzienlijke impact die op afstand kan worden geëxploiteerd), gemiddeld (prestatievermindering, beperkte reikwijdte) en laag (een moeilijk te exploiteren bug met een kleine impact). Er zal een oplossing worden ontwikkeld en in het geheim grondig worden getest zodra wordt bevestigd dat de kwetsbaarheid ernstig is. Deze oplossing wordt net als elke andere codewijziging in een PR ingediend. Maar de PR-discussie en -beschrijving vervagen de waarheid over de aard van deze oplossing. Deze oplossing kan worden omschreven als een “refactoring”, “prestatieverbetering” of “verharding tegen mogelijke problemen”. De oplossing kan vervolgens worden onderworpen aan normale codebeoordelingen, terwijl de details van de kwetsbaarheid privé blijven.

De aanpak is niet zonder uitdagingen. Het evenwicht bewaren kan een echte uitdaging zijn. Sommige critici zouden kunnen zeggen dat deze aanpak paternalistisch is, of dat de macht te sterk in de handen van een kleine groep ontwikkelaars wordt geconcentreerd. Zij kennen kwetsbaarheden als geen ander. Hoewel deze zorgen serieus moeten worden genomen, kunnen de gevolgen van een openbare aankondiging rampzalig blijken. Publicatie van kwetsbaarheidsdetails voorafgaand aan de update door de meeste gebruikers geeft aanvallers zowel het doelwit (niet-bijgewerkte apparaten) als het wapen (exploitcodes).

Fuzzende infrastructuur

Fuzzing, ook bekend als randomisatie, is een techniek om bugs in software te vinden door er willekeurige invoer aan toe te voegen. Fuzzers gebruiken evolutionaire algoritmen die leren welke input interessante codepaden veroorzaakt en die input vervolgens veranderen om dieper in de software te duiken. Dit is een geweldige manier om randgevallen te detecteren die moeilijk te ontdekken zijn via codebeoordelingen of handmatige tests.

Omdat de fuzzer input levert, kunnen ontwikkelaars niet direct aangeven wat ze verwachten (bijvoorbeeld dat input A output B moet opleveren). In plaats daarvan beweren ze algemene kenmerken die de software moet behouden. Het is een zeer waardevol hulpmiddel, omdat het ons helpt het vertrouwen op te bouwen dat de software zich zal gedragen zoals verwacht door eigenschappen te controleren, zoals voorkomen dat het netwerk crasht en ervoor zorgen dat de muntaanvoer niet groter is dan we verwachten.

Bitcoin Core heeft een hoog fuzzing-niveau vanwege de behoefte aan veiligheid en robuustheid. Fuzz-testen zijn in Bitcoin Core door de jaren heen toegenomen. Vroege vermeldingen van primitief fuzzing dateren uit de tijd 2012 De integratie van het eenvoudige raamwerk voor fuzzing vond plaats in 2016Het raamwerk is geëvolueerd en omvat nu meer dan 200 fuzz-tests die cruciale componenten en functies in de codebase bestrijken.

Fuzz-tests worden niet gedefinieerd door een standaard eenheidstest. “pass”-punt, dat wil zeggen dat als u ze slechts één keer uitvoert, ze niet zullen werken. “geslaagd” Hieronder volgen enkele voorbeelden van het gebruik van “mislukt” De status van de aangifte. Omdat fuzzing een willekeurig proces is dat voortdurend doorgaat, zullen uitspraken over de resultaten (als er geen bugs zijn gevonden) alleen maar probabilistisch zijn. Fuzz-tests kunnen tot 5000 uur continu worden uitgevoerd voordat een fout wordt ontdekt. Om echt effectief te zijn, moet de fuzz-test constant worden uitgevoerd. Bitcoin Core is afhankelijk van die van Google oss-fuzz Het investeert ook zwaar in zijn eigen infrastructuur, en verschillende bijdragers zijn voortdurend bezig met het vertroebelen van hun eigen opstellingen. Bijvoorbeeld: RandBitcoin Core wordt vertroebeld door één enkele infrastructuur, die meer dan 1 miljoen CPU-uren per jaar levert.

De Bitcoin Core-repository bevat talloze fuzz-tests op component-/functieniveaus, maar verschillende andere projecten gebruiken verschillende fuzz-technieken. Het inmiddels gepensioneerde Cryptofuzz ​​was een project dat zich richtte op het differentieel fuzzen van libsecp256k1-code en andere cryptografische componenten. Het project omvatte ook niet-cryptografische codes, zoals serialisatieprimitieven en consensuslogica. bitcoinfuzz Maakt gebruik van een Bitcoin-specifieke differentiële fuzzling-aanpak. Met behulp van fuzzing wordt een volledige systeemaanpak gecreëerd om bugs op systeemniveau te ontdekken. FuzzamotoDit wordt gebruikt om bugs te vinden die worden veroorzaakt door complexe interacties van verschillende codebases die als één systeem werken.

Er zijn honderden, zo niet duizenden insecten ontdekt. gevonden door te fuzzen In de door de jaren heen uitgebrachte Bitcoin Core-versies of pull-verzoeken (waarvan sommige uiteraard niet relevant zijn voor de veiligheid) wordt het belang en de effectiviteit van fuzzing benadrukt. Dit is een zeer ernstig voorbeeld dat onlangs werd gepubliceerd. CVE-2024-35202De ontdekking omvatte het herstructureren van de compacte blokrelaislogica, het extraheren ervan in een eigen geïsoleerde en testbare module en het schrijven van een fuzz-test ervoor. Het werd ontdekt door de logica van compacte blokrelais te extraheren en te testen en deze in hun eigen module te herstructureren.

Kwaliteitsborging

Hoewel fuzzing in de vorige sectie werd benadrukt, maakt het project ook regelmatig gebruik van andere testmethoden. Dit helpt de kans te verkleinen dat problemen de productiecode bereiken.

Bitcoin Core bevat honderden unit-tests. De tests verifiëren kleine stukjes code, zoals functies en klassen. Unit-testen worden bijvoorbeeld gebruikt om het gedrag van een functie te controleren voor proof-of-work. Bij deze tests worden edge-case-invoer aan de functie geleverd om te testen of de uitvoer aan de verwachtingen voldoet.

Functionele tests daarentegen testen een enkele Bitcoin Core-instantie of meerdere instanties in hun geheel, waarbij het gedrag van het systeem op een hoog niveau wordt geverifieerd met behulp van externe interfaces (om bijvoorbeeld scenario’s uit de echte wereld te simuleren, kunnen RPC’s en p2p-berichten worden gebruikt. Een test van dit type zou bijvoorbeeld een netwerk van kleine knooppunten kunnen creëren en aan elk van hen een betaling kunnen doen. De portemonnee-RPC’s worden gebruikt om te verifiëren dat het hele netwerk van knooppunten de transactie heeft waargenomen en goedgekeurd. Bitcoin Core ontbrak historisch gezien aan code modulariteit Dit kenmerk is vandaag de dag nog steeds aanwezig. Er is in het project gekozen voor een functionele testbenadering, in plaats van een traditionele unit-testing. Dit komt omdat de code moet worden geherstructureerd om deze te kunnen isoleren voor onafhankelijk testen.

Elke testmethodologie heeft zowel sterke als zwakke punten. De unittest is een snelle manier om bugs te vinden, en het is ook een goede methode om ze te lokaliseren. Per definitie zullen unit-tests geen bugs detecteren die alleen worden veroorzaakt door de interacties van verschillende eenheden. Functionele tests zijn het beste omdat ze het hele systeem testen, maar dit gaat ten koste van de snelheid. Ze moeten voor elke test knooppuntinstanties maken en verwijderen. Deze tests geven ook veel slechter aan waar de bug zich bevindt. In het vorige voorbeeld, het mislukken van de propagatietest (dat wil zeggen: het is moeilijk om te bepalen welke delen van het systeem een ​​bug hebben). Dit kan te wijten zijn aan een probleem met de logica van mempool accept, of de code voor netwerken, RPC’s die werden gebruikt om de transacties te maken, of andere componenten. De beste methode om te gebruiken is een combinatie van methoden.

Elke PR wordt via de CI gevoerd, evenals elke push van de master-branch. De unit-, fuzz- en functionele tests worden allemaal uitgevoerd op een verscheidenheid aan host-besturingssystemen, CPU-architecturen en bugdetectietools, waaronder de Address-, Thread-, Undefined- en Memory sanitizers, en valgrind, om veelvoorkomende C++-bugs te detecteren die verband houden met ongedefinieerd gedrag en geheugenveiligheid.

Bitcoin Core is stapsgewijs geëvolueerd van de client die Satoshi oorspronkelijk heeft uitgebracht. Bijdragers kwamen en gingen in de loop van de tijd, dus er is een grote hoeveelheid verouderde code. Het is en blijft een belangrijk onderdeel van het werk in het Bitcoin Core-project, waarbij de bestaande code wordt geherstructureerd. Dit wordt gedaan om het voor de gebruiker eenvoudiger en gemakkelijker te maken. Al deze dingen vereisen refactoring, ongeacht of het voor de kernel is. Er zijn verschillende meningen over hoe en wanneer te herstructureren, omdat het een tweesnijdend zwaard is. Refactoring kan beangstigend zijn, omdat het nieuwe bugs kan introduceren, maar ook de context van degenen die erbij betrokken zijn kan vernieuwen. Functionele tests en tests op systeemniveau (zoals Fuzzamoto in de paragraaf over fuzzing) kunnen worden gebruikt om het risico op refactoring te verkleinen. Dit komt omdat deze tests zeer weinig refactoring vereisen.

Het project produceert, als onderdeel van de teststrategie voorafgaand aan grote releases en als een manier om gebruikers aan te moedigen nieuwe en gevestigde functies uit te proberen, een handleiding waarmee ze deze handmatig kunnen testen. Als algemene oproep tot actie om ervoor te zorgen dat de normale workflow van elke gebruiker behouden blijft, wordt het testen van software met normaal gebruik aangemoedigd.

Mis uw kans niet om eigenaar te worden Het kernprobleem – met artikelen geschreven door veel kernontwikkelaars waarin de projecten worden uitgelegd waaraan ze zelf werken!

In het nieuwste nummer van het tijdschrift staat een brief aan de redacteur. Afdrukken Dit is de kernuitgave van Bitcoin Magazine. Dit is een voorproefje van het hele nummer.