Weiter zum Hauptinhalt

Helfen Sie mit, diese Seite zu übersetzen

🌏

Sie sehen diese Seite auf Englisch, weil wir sie noch nicht übersetzt haben. Helfen Sie mit, die Inhalte zu übersetzen.

Seite übersetzen

Hier sind keine Fehler!🐛

Diese Seite wird nicht übersetzt. Wir haben diese Seite bewusst vorerst auf Englisch belassen.

Für Einreichungen offen

Konsens-Layer-Bug-Bounties 🐛
Verdienen Sie bis zu 50.000 USD und einen Platz auf der Rangliste, indem Sie Konsens-Layer-Protokoll- und Client-Fehler finden.
Fehler meldenRegeln lesen
1
protolambda GitHub avatar
protolambda
42400 Punkte
🏆
2
guidovranken GitHub avatar
Guido Vranken
39350 Punkte
🥈
3
holiman GitHub avatar
Martin Holst Swende
38000 Punkte
🥉
4
samczsun GitHub avatar
Sam Sun
35000 Punkte
5
chainsecurity GitHub avatar
ChainSecurity
21000 Punkte
Vollständige Rangliste anzeigen

In den Belohnungen aufgeführte Clients

Gültige Fehler

Dieses Bug-Bounty-Programm konzentriert sich auf die Suche nach Fehlern in der Beacon Chain-Spezifikation und den Lighthouse-, Nimbus-, Teku-, Prysm- und Lodestar-Client-Implementierungen.

📒

Die Fehler in der Spezifikation der Beacon Chain

Die Beacon Chain-Spezifikation beschreibt das Designprinzip und die vorgeschlagenen Änderungen an Ethereum durch das Beacon Chain-Upgrade.

Vollständige Spezifikation lesen
Execution Layer Specifications

Es könnte hilfreich sein, die folgenden Anmerkungen zu prüfen:

Fehlerarten

  • Sicherheits-/endgültigkeitsverletzende Fehler
  • Denial-of-Service (DOS)-Vektoren
  • Inkonsistenzen in den Annahmen, wie Situationen, in denen ehrliche Validatoren geslasht werden
  • Berechnungs- oder Parameterinkonsistenzen

Spezifikationsdokumente

Beacon Chain
Auswahl forken
Solidity-Deposit-Vertrag
Peer-to-Peer-Netzwerk
💻

Client-Fehler im Konsens-Layer

Die Clients führen die Beacon Chain aus, sobald das Upgrade installiert ist. Die Clients müssen der in der Spezifikation dargelegten Logik folgen und gegen mögliche Angriffe geschützt sein. Die Fehler, die wir finden wollen, stehen in Zusammenhang mit der Implementierung des Protokolls.

Derzeit sind Lighthouse-, Nimbus-, Teku- und Prysm-Fehler für die vollen Bounty-Belohnungen berechtigt. Lodestar ist ebenfalls teilnahmeberechtigt, aber bis weitere Audits abgeschlossen sind, sind die Punkte und Prämien auf 10 % begrenzt (maximale Auszahlung beträgt 5.000 DAI). Weitere Clients können hinzugefügt werden, wenn sie Audits abschließen und produktionsbereit sind.

Fehlerarten

  • Probleme mit der Nichteinhaltung der Spezifikation
  • Unerwartete Abstürze oder Denial-of-Service (DOS)-Schwachstellen
  • Alle Probleme, die irreparable Abspaltungen vom Konsens des restlichen Netzwerks verursachen

Hilfreiche Links

Besu
Erigon
Geth
Lighthouse
Lodestar
Nimbus
Nethermind
Prysm
Teku
📖

Solidity bugs

See the Solidity SECURITY.MD for more details about what is included in this scope.

Solidity does not hold security guarantees regarding compilation of untrusted input – and we do not issue rewards for crashes of the solc compiler on maliciously generated data.

Hilfreiche Links

SECURITY.md
📜

Deposit Contract bugs

The specificiations and source code of the Beacon Chain Deposit Contract is part of the bug bounty program.

Nicht enthalten

Die Zusammenführung und die Shard-Chain- und Docking-Upgrades befinden sich derzeit noch in der Entwicklung und sind daher noch nicht Teil dieses Belohnungsprogramms.

Fehler melden

Für jeden Fehler, den Sie finden, werden Sie mit Punkten belohnt. Die Punkte, die Sie verdienen, hängen vom Schweregrad des Fehlers ab. Lodestar-Fehler werden derzeit mit 10 % der unten aufgeführten Punkte ausgezeichnet, da weitere Audits abgeschlossen werden müssen. Die Ethereum Foundation (EF) bestimmt den Schweregrad mit der OWASP-Methode. OWASP-Methode anzeigen

Die EF vergibt ebenfalls Punkte, basierend auf:

Beschreibungsqualität: Höhere Prämien werden für klare, gut geschriebene Beiträge gezahlt.

Qualität der Reproduzierbarkeit: Bitte fügen Sie Testcode, Skripte und detaillierte Anweisungen bei. Je einfacher es für uns ist, die Vulnerabilität zu reproduzieren und zu überprüfen, desto höher die Belohnung.

Qualität der Korrektur, falls enthalten: Für Einreichungen mit einer klaren Beschreibung der Problemlösung werden höhere Prämien bezahlt.

Bis zu 2.000 DAI

Gering

Bis zu 2.000 DAI

Bis zu 1.000 Punkte

Schweregrad

  • Geringe Auswirkung, mittlere Wahrscheinlichkeit
  • Mittlere Auswirkung, geringe Wahrscheinlichkeit

Beispiel

Ein Angreifer kann manchmal einen Knoten in einen Zustand versetzen, der ihn dazu veranlasst, eine von hundert Bescheinigungen zu verlieren, die von einem Validator gemacht wurden
Fehler mit geringem Risiko melden
Bis zu 10.000 DAI

Mittel

Bis zu 10.000 DAI

Bis zu 5.000 Punkte

Schweregrad

  • Hohe Auswirkung, geringe Wahrscheinlichkeit
  • Mittlere Auswirkung, mittlere Wahrscheinlichkeit
  • Geringe Auswirkung, hohe Wahrscheinlichkeit

Beispiel

Ein Angreifer kann erfolgreich einen Eclipse-Angriff auf Knoten mit Peer-IDs mit 4 führenden Nullbytes ausführen
Fehler mit mittlerem Risiko melden
Bis zu 20.000 DAI

Hoch

Bis zu 20.000 DAI

Bis zu 10.000 Punkte

Schweregrad

  • Hohe Auswirkung, mittlere Wahrscheinlichkeit
  • Mittlere Auswirkung, hohe Wahrscheinlichkeit

Beispiel

Es gibt einen Konsensfehler zwischen zwei Clients, aber es ist schwierig oder unpraktisch für den Angreifer, das Ereignis auszulösen.
Fegker mit hohem Risiko melden
Bis zu 50.000 DAI

Kritisch

Bis zu 50.000 DAI

Bis zu 25.000 Punkte

Schweregrad

  • Hohe Auswirkung, hohe Wahrscheinlichkeit

Beispiel

Es gibt einen Konsensfehler zwischen zwei Clients und es ist trivial für einen Angreifer, das Ereignis auszulösen.
Fehler mit kritischem Risiko melden

Regeln für die Fehlersuche

Das Fehlerbelohnungsprogramm ist ein experimentelles, unserem Ermessen überlassenes Prämienprogramm für unsere aktive Ethereum-Community, um diejenigen zu ermuntern und zu belohnen, die zur Verbesserung der Plattform beitragen. Es ist kein Wettbewerb. Hinweis: Wir behalten uns vor, das Programm jederzeit zu beenden. Auszeichnungen werden nach alleinigem Ermessen des Bug-Bounty-Programm-Gremiums der Ethereum Foundation vergeben. Außerdem können wir keine Auszeichnungen an Personen vergeben, die auf Sanktionslisten stehen oder sich in Ländern auf Sanktionslisten befinden (bspw. in Nordkorea, Iran etc.). Jeder ist selbst für die korrekte Versteuerung verantwortlich. Alle Auszeichnungen unterliegen dem geltenden Recht. Das Testen darf zudem keine Gesetze verletzen oder Daten kompromittieren, die nicht die eigenen sind.

  • Probleme, die bereits von einem anderen Nutzer eingereicht wurden oder die bereits Spezifikations- oder Client-Betreuern bekannt sind, berechtigen nicht zu Belohnungsprämien.
  • Die öffentliche Bekanntgabe einer Sicherheitslücke führt dazu, dass sie nicht für eine Belohnung in Frage kommt.
  • Forscher der Ethereum Foundation und Mitarbeiter von Konsens-Layer-Kundenteams haben keinen Anspruch auf Belohnungen.
  • Das Ethereum Bounty-Programm berücksichtigt eine Reihe von Variablen bei der Bestimmung der Belohnungen. Die Anspruchsprüfung, die Berechnung des Ergebnisses und alle weiteren Bestimmungen bezüglich einer Belohnung liegen im alleinigen und endgültigen Ermessen des Ethereum Foundation-Bug-Bounty-Panels.

Execution Layer Bug Bounty leaderboard

Find execution layer bugs to get added to this leaderboard

1
holiman GitHub avatar
Martin Holst Swende
35500 Punkte
🏆
2
samczsun GitHub avatar
Sam Sun
35000 Punkte
🥈
3
guidovranken GitHub avatar
Guido Vranken
21750 Punkte
🥉
4
chainsecurity GitHub avatar
ChainSecurity
21000 Punkte
5
junorouse GitHub avatar
Juno Im
20500 Punkte
6
uknowy GitHub avatar
Yoonho Kim (team Hithereum)
20000 Punkte
7
johnyangk GitHub avatar
John Youngseok Yang (Software Platform Lab)
20000 Punkte
8
peckshield GitHub avatar
PeckShield
17000 Punkte
9
itsunixiknowthis GitHub avatar
ItsUnixIKnowThis
15000 Punkte
10
catageek GitHub avatar
Bertrand Masius
15000 Punkte
11
tintinweb GitHub avatar
Tin
12500 Punkte
12
Ralph Pichler
12500 Punkte
13
Bob Conan
12000 Punkte
14
lukaszmatczak GitHub avatar
Łukasz Matczak
11000 Punkte
15
Heilman/Marcus/Goldberg
10000 Punkte
16
jonasnick GitHub avatar
Jonas Nick
10000 Punkte
17
jtoman GitHub avatar
John Toman
10000 Punkte
18
Sebastian Henningsen
8000 Punkte
19
Dominic Brütsch
7500 Punkte
20
HarryR GitHub avatar
Harry Roberts
5000 Punkte
21
p- GitHub avatar
Peter Stöckli
5000 Punkte
22
Dedaub GitHub avatar
Neville Grech
5000 Punkte
23
EthHead GitHub avatar
EthHead
5000 Punkte
24
axic GitHub avatar
Alex Beregszaszi
3500 Punkte
25
SergioDemianLerner GitHub avatar
Sergio Demian Lerner
2500 Punkte
26
danhper GitHub avatar
Daniel Perez
2500 Punkte
27
yaronvel GitHub avatar
Yaron Velner
2000 Punkte
28
whitj00 GitHub avatar
Whit Jackson
2000 Punkte
29
Ming Chuan Lin
2000 Punkte
30
melonport GitHub avatar
Melonport team
2000 Punkte
31
maurelian GitHub avatar
Maurelian
2000 Punkte
32
Cjentzsch GitHub avatar
Christoph Jentzsch
2000 Punkte
33
hwanjo GitHub avatar
Hwanjo Heo
1500 Punkte
34
DVPNET GitHub avatar
DVP (dvpnet.io)
1200 Punkte
35
Vasily Vasiliev
1000 Punkte
36
talko GitHub avatar
talko
1000 Punkte
37
swaldman GitHub avatar
Steve Waldman
1000 Punkte
38
ptk GitHub avatar
Panu Kekäläinen
1000 Punkte
39
montyly GitHub avatar
Josselin Feist
1000 Punkte
40
henrit GitHub avatar
Henrit
1000 Punkte
41
BlameByte GitHub avatar
Marc Bartlett
1000 Punkte
42
Barry Whitehat
1000 Punkte
43
badmofo GitHub avatar
Lucas Ryan
1000 Punkte
44
agroce GitHub avatar
Alex Groce
1000 Punkte
45
n0thingness GitHub avatar
Daniel Briskin
750 Punkte
46
daenamkim GitHub avatar
Daenam Kim
750 Punkte
47
Myeongjae Lee
500 Punkte
48
Marcin Noga (Cisco/Talos Security)
500 Punkte
49
jazzybedi
500 Punkte
50
feeker GitHub avatar
Feeker - 360 ESG Codesafe Team
500 Punkte
51
ethernomad GitHub avatar
Jonathan Brown
500 Punkte
52
davidmurdoch GitHub avatar
David Murdoch
500 Punkte
53
wadeAlexC GitHub avatar
Alexander Wade
500 Punkte
54
gitpusha GitHub avatar
Luis Schliesske
200 Punkte

Häufig gestellte Fragen

What should a good vulnerability submission look like?

See a real example of a quality vulnerability submission.

Description: Remote Denial-of-service using non-validated blocks

Attack scenario: An attacker can send blocks that may require a high amount of computation (the maximum gasLimit) but has no proof-of-work. If the attacker sends blocks continuously, the attacker may force the victim node to 100% CPU utilization.

Impact: An attacker can abuse CPU utilization on remote nodes, possibly causing full DoS.

Components: Go client version v0.6.8

Reproduction: Send a block to a Go node that contains many txs but no valid PoW.

Details: Blocks are validated in the method Process(Block, dontReact). This method performs expensive CPU-intensive tasks, such as executing transactions (sm.ApplyDiff) and afterward it verifies the proof-of-work (sm.ValidateBlock()). This allows an attacker to send blocks that may require a high amount of computation (the maximum gasLimit) but has no proof-of-work. If the attacker sends blocks continuously, the attacker may force the victim node to 100% CPU utilization.

Fix: Invert the order of the checks.

Is the bug bounty program is time limited?

No.

No end date is currently set. See the Ethereum Foundation blog for the latest news.

How are bounties paid out?

Rewards are paid out in ETH or DAI.

Rewards are paid out in ETH or DAI after the submission has been validated, usually a few days later. Local laws require us to ask for proof of your identity. In addition, we will need your ETH address.

Can I donate my reward to charity?

Yes!

We can donate your reward to an established charitable organization of your choice.

I reported an issue / vulnerability but have not received a response!

Please allow a few days for someone to respond to your submission.

We aim to respond to submissions as fast as possible. Feel free to email us at bounty@ethereum.org if you have not received a response within a day or two.

I want to be anonymous / I do not want my name on the leader board.

You can do this, but it might make you ineligble for rewards.

Submitting anonymously or with a pseudonym is OK, but will make you ineligible for ETH/DAI rewards. To be eligible for ETH/DAI rewards, we require your real name and a proof of your identity. Donating your bounty to a charity doesn’t require your identity.

Please let us know if you do not want your name/nick displayed on the leader board.

What are the points in the leaderboard?

Every found vulnerability / issue is assigned a score

Every found vulnerability / issue is assigned a score. Bounty hunters are ranked on our leaderboard by total points.

Do you have a PGP key?

Yes. Expand for details.

Please use AE96 ED96 9E47 9B00 84F3 E17F E88D 3334 FA5F 6A0A

PGP Key

Fragen?

Senden Sie uns eine E-Mail an: bounty@ethereum.org

✉️

War diese Seite hilfreich?