Recompensamos aqueles que dedicam tempo e esforço para melhorar a plataforma RSK
Regras e recompensas
Envie suas descobertas e ganhe recompensas
O remetente deve ser a pessoa que descobriu a vulnerabilidade. O envio de vulnerabilidades não pode ser delegado.
Aceitamos envios anônimos, mas, nesse caso, a recompensa será doada para caridade.
O remetente concede à RSK o direito de usar partes ou todo o conteúdo do relatório enviado para comunicar a vulnerabilidade ao público.
A RSK pode citar o nome do remetente e os pontos ganhos nos posts do blog da RSK e nos rankings de recompensas on-line.
Se preferir não ser identificado nas comunicações da RSK pelo seu nome verdadeiro, você deve comunicar isso de forma explícita e fornecer um pseudônimo em seu envio.
Problemas que já foram enviados por outro usuário ou que já são conhecidos da equipe RSK não são qualificados para recompensas.
Vulnerabilidades já tornadas públicas não são elegíveis para uma recompensa. Se o usuário relatar a vulnerabilidade a outras equipes de segurança (por exemplo, Ethereum ou ETC), mas reportar à RSK com atraso considerável, a RSK poderá reduzir ou cancelar a recompensa.
Você pode iniciar ou bifurcar uma cadeia privada para procurar bugs. Evite atacar a cadeia principal da RSK e as redes de teste. Também evite atacar as cadeias principais ETH ou ETC e as redes de teste. Um ataque tornará a vulnerabilidade inelegível para recompensa.
A equipe de desenvolvimento da RSK, funcionários e todas as outras pessoas remuneradas direta ou indiretamente pela RSK não são elegíveis para recompensas.
Uma pessoa que enviou uma alteração na base de código da RSK não está qualificada para recompensas por vulnerabilidades originadas ou acionadas pela alteração enviada.
Sites, infraestrutura e ativos da RSK NÃO fazem parte do programa de recompensas.
O programa de recompensas da RSK considera diversas variáveis na determinação de recompensas.
Determinações de elegibilidade, pontuação e todos os termos relacionados a um prêmio ficam a critério exclusivo e absoluto da RSK Labs.
Exemplos
O valor das recompensas pagas variará de acordo com a gravidade dos problemas identificados. A gravidade é calculada de acordo com o modelo de classificação de risco OWASP baseado em Impacto e Probabilidade
Um erro desencadeado por uma única transação de baixo custo que bifurca o RSK blockchain em alguns nós aceitando um bloco que contém a transação e alguns nós rejeitando esse bloco geralmente será considerado de Alta gravidade.
Isso ocorre devido à alta probabilidade de que seja usado para um ataque, mas o impacto é médio, porque um ataque de gasto duplo também deve ser perpetrado para roubar ativos.
Um ataque remoto a um nó específico que rouba suas chaves privadas com uma probabilidade muito baixa será considerado de Alta gravidade.
Isso ocorre porque o impacto é alto, mas a probabilidade é média, e muitos nós devem ser investigados até que o invasor encontre a vítima certa.
Um ataque que envia o blockchain como spam ou o estado com um custo muito menor do que o esperado, será geralmente considerado de Média gravidade.
Um ataque remoto que revela alguma informação privada de um nó que não causa a perda de fundos será considerado de Baixa gravidade.
Nosso programa de recompensas de bugs cobre de ponta a ponta
Da solidez dos protocolos (como o
modelo de consenso de blockchain, os protocolos wire e p2p, prova de trabalho, etc.) e implementação de protocolo. A segurança clássica
do cliente, bem como a segurança de primitivas criptográficas, também fazem parte do programa. Detalhes sobre o escopo a seguir:
A pilha de protocolos RSK tem algumas semelhanças com o Ethereum, mas difere em muitos aspectos. A maioria dos protocolos, como o consenso, a sincronização do blockchain, a árvore trie de estado e o EVM, foram redesenhados ou modificados. Como não há descrição formal desses novos protocolos, as vulnerabilidades no design do protocolo seriam avaliadas em relação à funcionalidade pretendida, o que pode não ser evidente.
Incentivamos os pesquisadores a procurar problemas no design das seguintes áreas:
Ponte de bitcoin (conexão bilateral)
Gestão de membros da federação
Algoritmo de ajuste de dificuldade de bloco
Incentivos de mineração “selfish”
Segurança SPV
Incentivos de mineração “uncle”
Segurança da árvore trie de estado
Incentivos econômicos desalinhados / não intencionais e falhas teóricas de jogos.
Fraquezas / ataques de segurança ao algoritmo PoW ou ao sistema de mineração de mesclagem.
Um exemplo concreto poderia ser um contrato que consome muito pouco combustível, mas leva a um grande esforço computacional para abrir efetivamente a porta para ataques DoS.
Supondo que os designs de protocolos e de algoritmos são perfeitos, a implementação de um cliente está de acordo com o comportamento pretendido? Os problemas podem incluir:
Validações de blocos, transações e mensagens
Execução de código da máquina virtual RSK
Execução de transação
Criação de contrato
Chamadas de mensagem
Cálculo e execução de combustível e taxas
Esta categoria concentra-se em ataques generalizados em toda a rede ou em um subconjunto dela:
51% e outros X% de ataques.
Ataques de isolamento
Ataques de Finney.
Ataques de Sybil.
Ataques de repetição.
Maleabilidade de transações / mensagens.
DoS (global).
Ataques em um único cliente RSK relacionado à plataforma RSK:
Abuso de DoS / recursos
Coleta / sondagem de endereço de conta / carteira
Ataques de transmissão / retenção
Esta categoria aborda questões de segurança mais clássicas:
Sobrefluxo / cruzamento de tipo de dados, por exemplo, estouro de inteiro.
Pânico ou erros tratados inadequadamente.
Concorrência, por exemplo, sincronização, estado, competições.
Problemas relacionados a bibliotecas externas usadas.
Esta categoria inclui:
Implementação / uso / configuração incorreta de:
Curva elíptica (secp256k1, ECDSA).
Algoritmos de hash (Keccak-256).
Árvores de Merkle Patricia.
Gerenciamento de chaves
Qualidade de fonte aleatória
Canais laterais e vazamentos de informações
Quer saber mais?