From nobody Thu Sep 24 14:25:58 2026 Received: from mail-vs2-f41.google.com (mail-vs2-f41.google.com [74.125.227.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8452833A9F3 for ; Wed, 23 Sep 2026 02:52:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.227.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790131983; cv=none; b=SbzDPOPLn5/JiPLBu/nSgvU2OKt6em+IDSurHkMQI1HGLjFALBMUr8mF/CbN2+y3LTXud8BUaXilaUTidP2enepEjj6rlz6eRyYxEjd6srM4bDXQyV0UfOnH8O3CdK9F2Ra7qtxswWAIdtmLQx59TlQMYd7Tpb20wE95Qquj0q0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790131983; c=relaxed/simple; bh=a7+pLpf6YkrQIyxveWCVHFRO1MNao1SDWaNEpRApMtI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=AsWICTi6hSvEKvQJhsH70RGZkdA+PcYUthg70i9T/k1wJR+pVxxzoMDYKB78UNoPWAHRvRol1/KW7uuaOoLc8bzwW5tysozTT3de108iFyoqiKRHKI1ZxbQnpGRGl9ZNQOugQdv2/QM4pYYXlK2yNGYeb6BptpM7OWgtPNIA5i0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=sny0b9Zh; arc=none smtp.client-ip=74.125.227.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="sny0b9Zh" Received: by mail-vs2-f41.google.com with SMTP id ada2fe7eead31-791a9878aa9so178828137.0 for ; Tue, 22 Sep 2026 19:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790131977; x=1790736777; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=K3s2p1CE2vkwr8sxWmng4sP6dTrRmCWsuND9yv4ilZA=; b=sny0b9ZhEVdeax+v2frlIyF40uDMQV4T2M0B+RvdkYiTgRHm3Uc8mrKOmdFJx4SsAS eYREtdlyK1muK7iIHNrICUe5TAEQcLcQ3Wqh9pzxVe46cO6u6JRha9fTRV0ES8AH6puB VOGFP1k7vdNRfCzhGdXa4NWcw1dePBFj82OecCG6J3YNlhD6pD2YXbnYE0hmrRAfSRGz PsxzM7I0bGOwfZZ6XN7lwWu/IDEVtRmTiTKaxcChd/cxgf3JlBuOFPMZUIoS60NMhvZ4 19Ll5nJ+hH5swMpZFuxCGzussEqBxhhJv1JleBZseTsi0sYskMHNkMzkqMxcNU8v4g+0 OAyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790131977; x=1790736777; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=K3s2p1CE2vkwr8sxWmng4sP6dTrRmCWsuND9yv4ilZA=; b=WZUYoJTU9ihklEnnt1Tybjd0jmX7HJBUWBL5epoBRu/3K2I2RDv6L1y0QQzswgdFdg DKVJvufbRE6M2kauWwHI9HR+Bq+HP9Q4Je6SO7N8mWIx8S2DP3FNCwed+N65HfJHMkCg XrZX0RCfIB7VxP6IJ0bXUoCIfaX5HPr4i5suwQMdJpUlUAP3Q0+u0T4waQXNrDnXl/43 Humz6W2lsV4qIT8B9f/PDY/gpxUFVb46z1LknhtlOqNT2r+ElStH6QWSeVebD5hBKunr So/dUGtQZI8eZDtT6kU5QBassOgMT2VNqB0u1sXU2yHE0L6yWdanG171gEOCGn5EBtN/ 1VEw== X-Forwarded-Encrypted: i=1; AKwUvByxu/pXSAm9UH2thFbsgbh7Zn/RuJql0/NAWboTU6o4uYmR2usbj7ky6Idae6Ky1oXRedsx5U70rpTdc04=@vger.kernel.org X-Gm-Message-State: AFuF++mOtFel8REemVPKrt3oA0OfcsCkiCBUFnCNl2keWUPbBFPxLjVv Xnj775k3ApYLmOLlg8i4NT0MU1KqKOdnlDX2p5o7aVdhigpmYjOm3+AF X-Gm-Gg: AYBFou1ID9qufle+91nRU8y9p+9HXV8dferrPdlEfsiE7iAyLN+PUHqqRq5RQh0dBA0 DZMuZHJ6x7bCmjlH1BDz8QP1CAJox/iJJFsGTNQ/NP0jTj/gz+4sIS54vPjY70hkPNcLXVsv3IV aPd++ykG3h2cMhey8uA5j+wWjb3NUME6kL+I5xEldYjfjsRPu59BIbYuy36DdY3ToMMLrCkDIQb v+JKvqPUIK81nCDl0/c5qVpbr3QHfDy5KI0gSFgWHMcbWbRT5nxZx31CwhUWKZFi0BgHycYhFWS Yf/WTTLfEzrLUv6ZyBjGOWsp/DcwPqX9FmwJxF3RkSKUe6ii+3qXStoHpCJam3308P3L4WQu+BD CINLXoOoIOE1EiPiROqYhQIxvFHw9BwEhYIlDvdXjMDulIh4BM/T82cwsojnx1556iQmTs4oklJ J8mlRTQCnwGrGzd6k7TnhJiwxLQIWSfZcQuX0avMuFwT4eATQhVmQsb4FZnuJ4UaX70cn8P27Ap YxKzLAZxIhQRs5pW2E= X-Received: by 2002:a05:6102:6b0a:b0:7a8:10eb:96c4 with SMTP id ada2fe7eead31-7ac1d4eb126mr1279244137.20.1790131977369; Tue, 22 Sep 2026 19:52:57 -0700 (PDT) Received: from localhost.localdomain ([2804:7f0:9f80:9f3c:2a83:211a:9e77:570c]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-7abf5a7fb17sm2031125137.7.2026.09.22.19.52.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Sep 2026 19:52:56 -0700 (PDT) From: vinihsr To: Daniel Pereira , Jonathan Corbet Cc: Shuah Khan , Randy Dunlap , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Vinicius Henrique Subject: [PATCH v3] docs: translations: pt_BR: translate threat-model.rst Date: Tue, 22 Sep 2026 23:51:48 -0300 Message-Id: <20260923025148.35637-1-vinicius.m1821@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260922031247.182335-1-vinicius.m1821@gmail.com> References: <20260922031247.182335-1-vinicius.m1821@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Vinicius Henrique Translate threat-model.rst into Brazilian Portuguese, maintaining consistency with original formatting rules. And add it to the pt_BR process documentation index. Assisted-by: LLM Signed-off-by: Vinicius Henrique --- Changes in v3: - Fixed author name and grouped trailer tags. - Added SPDX-License-Identifier to threat-model.rst. - Fixed document title in the index.rst entry (changed to singular). - Corrected capitalization for "UNIX" and "Vazamentos". - Fixed verb agreement ("atribuam"). - Standardized terminology to match other pt_BR documents ("namespace de us= u=C3=A1rio", "forks", "fortificado", "sem resposta"). - v2: https://lore.kernel.org/r/20260922031247.182335-1-vinicius.m1821@gmai= l.com .../translations/pt_BR/process/index.rst | 1 + .../pt_BR/process/threat-model.rst | 259 ++++++++++++++++++ 2 files changed, 260 insertions(+) create mode 100644 Documentation/translations/pt_BR/process/threat-model.r= st diff --git a/Documentation/translations/pt_BR/process/index.rst b/Documenta= tion/translations/pt_BR/process/index.rst index 2c63d82bf..de716743e 100644 --- a/Documentation/translations/pt_BR/process/index.rst +++ b/Documentation/translations/pt_BR/process/index.rst @@ -78,6 +78,7 @@ gerenciamento de bugs e vulnerabilidades. :maxdepth: 1 =3D Falhas de seguran=C3=A7a + Modelo de amea=C3=A7as do kernel do Linux Problemas de hardware sob embargo CVEs =20 diff --git a/Documentation/translations/pt_BR/process/threat-model.rst b/Do= cumentation/translations/pt_BR/process/threat-model.rst new file mode 100644 index 000000000..cae2d4e85 --- /dev/null +++ b/Documentation/translations/pt_BR/process/threat-model.rst @@ -0,0 +1,259 @@ +.. SPDX-License-Identifier: GPL-2.0 + +O modelo de amea=C3=A7as do kernel do Linux +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Existem muitas suposi=C3=A7=C3=B5es sobre o que o kernel protege e o que n= =C3=A3o protege. +Essas suposi=C3=A7=C3=B5es tendem a causar confus=C3=A3o nos relat=C3=B3ri= os de bugs +(:doc:`relacionados =C3=A0 seguran=C3=A7a ` vs :doc:`n=C3= =A3o relacionados =C3=A0 +seguran=C3=A7a <../../../admin-guide/reporting-issues>`), e podem complica= r a +aplica=C3=A7=C3=A3o das medidas de seguran=C3=A7a quando as responsabilida= des por certos +limites n=C3=A3o est=C3=A3o claras entre o kernel, as distribui=C3=A7=C3= =B5es, os administradores e +os usu=C3=A1rios. + +Este documento tenta esclarecer as responsabilidades do kernel neste dom= =C3=ADnio. + +As responsabilidades do kernel +------------------------------ + +O kernel abstrai o acesso aos recursos de hardware locais e a sistemas rem= otos +de forma a permitir que m=C3=BAltiplos usu=C3=A1rios locais obtenham uma p= arcela justa dos +recursos dispon=C3=ADveis concedidos a eles e, quando o hardware subjacent= e permitir, +atribuam um n=C3=ADvel de confidencialidade =C3=A0s suas comunica=C3=A7=C3= =B5es e aos dados que +est=C3=A3o processando ou armazenando. + +O kernel presume que o hardware subjacente se comporta de acordo com suas +especifica=C3=A7=C3=B5es. Isso inclui a integridade do conjunto de instru= =C3=A7=C3=B5es da CPU, a +transpar=C3=AAncia da unidade de previs=C3=A3o de desvios e das unidades d= e cache, a +consist=C3=AAncia da Unidade de Gerenciamento de Mem=C3=B3ria (MMU), o iso= lamento de +perif=C3=A9ricos com capacidade de DMA (por exemplo, via IOMMU), transi=C3= =A7=C3=B5es de estado +nos controladores, intervalos de valores lidos dos registradores, o respei= to =C3=A0s +limita=C3=A7=C3=B5es de hardware documentadas, etc. + +Quando o hardware n=C3=A3o consegue manter o isolamento especificado (por = exemplo, +falhas na CPU, canais laterais, resposta do hardware a entradas inesperada= s), o +kernel geralmente tenta implementar medidas de mitiga=C3=A7=C3=A3o razo=C3= =A1veis. Trata-se de +medidas de melhor esfor=C3=A7o destinadas a reduzir a superf=C3=ADcie de a= taque ou elevar +o custo de um ataque dentro dos limites dos recursos do hardware; elas n= =C3=A3o +constituem uma garantia de seguran=C3=A7a fornecida pelo kernel. + +Os usu=C3=A1rios sempre realizam suas atividades sob a autoridade de um ad= ministrador +capaz de conceder ou negar v=C3=A1rios tipos de permiss=C3=B5es que podem = afetar a forma +como os usu=C3=A1rios se beneficiam dos recursos dispon=C3=ADveis ou o n= =C3=ADvel de +confidencialidade de suas atividades. Os administradores tamb=C3=A9m podem= delegar +todas ou parte de suas pr=C3=B3prias permiss=C3=B5es a alguns usu=C3=A1rio= s, particularmente +por meio de capacidades (capabilities), mas n=C3=A3o apenas. Tudo isso =C3= =A9 realizado +por meio de configura=C3=A7=C3=A3o (sysctl, permiss=C3=B5es do sistema de = arquivos, etc.). + +O kernel do Linux aplica um determinado conjunto de configura=C3=A7=C3=B5e= s padr=C3=A3o que +correspondem ao seu modelo de amea=C3=A7as. As distribui=C3=A7=C3=B5es t= =C3=AAm seu pr=C3=B3prio modelo +de amea=C3=A7as e v=C3=AAm com suas pr=C3=B3prias predefini=C3=A7=C3=B5es = de configura=C3=A7=C3=A3o, as quais o +administrador pode ter que ajustar para melhor atender =C3=A0s suas expect= ativas +(flexibilizar ou restringir). + +Por padr=C3=A3o, o kernel do Linux garante as seguintes prote=C3=A7=C3=B5e= s ao ser executado em +processadores comuns que possuem n=C3=ADveis de privil=C3=A9gio e unidades= de +gerenciamento de mem=C3=B3ria: + +* **Isolamento baseado no usu=C3=A1rio**: um usu=C3=A1rio sem privil=C3=A9= gios pode restringir + o acesso aos seus pr=C3=B3prios dados por parte de outros usu=C3=A1rios = sem privil=C3=A9gios + que estejam executando no mesmo sistema. Isso inclui: + + * dados armazenados, por meio de permiss=C3=B5es do sistema de arquivos + * dados na mem=C3=B3ria (as p=C3=A1ginas n=C3=A3o s=C3=A3o acess=C3=ADve= is, por padr=C3=A3o, a outros + usu=C3=A1rios) + * atividade do processo (o ptrace n=C3=A3o =C3=A9 permitido a outros usu= =C3=A1rios) + * comunica=C3=A7=C3=A3o entre processos (outros usu=C3=A1rios n=C3=A3o p= odem observar os dados + trocados por meio de UNIX domain sockets ou outros mecanismos de IPC). + * comunica=C3=A7=C3=B5es de rede dentro do mesmo sistema ou com outros s= istemas + +* **Prote=C3=A7=C3=A3o baseada em capacidades**: + + * usu=C3=A1rios que n=C3=A3o possuam capacidades elevadas (incluindo, ma= s n=C3=A3o se + limitando a CAP_SYS_ADMIN) n=C3=A3o podem alterar a configura=C3=A7=C3= =A3o, a mem=C3=B3ria nem o + estado do kernel, modificar a vis=C3=A3o de outros usu=C3=A1rios sobre= o layout do + sistema de arquivos, conceder a qualquer usu=C3=A1rio capacidades que = ele n=C3=A3o + possua, nem afetar a disponibilidade do sistema (desligamento, + reinicializa=C3=A7=C3=A3o, p=C3=A2nico, travamento ou tornar o sistema= n=C3=A3o responsivo por + esgotamento ilimitado de recursos). + * usu=C3=A1rios que n=C3=A3o possuam a capacidade ``CAP_NET_ADMIN`` n=C3= =A3o podem alterar a + configura=C3=A7=C3=A3o de rede, interceptar nem falsificar comunica=C3= =A7=C3=B5es de rede de + outros usu=C3=A1rios ou sistemas. + * usu=C3=A1rios que n=C3=A3o possuam ``CAP_SYS_PTRACE`` n=C3=A3o podem o= bservar as atividades + dos processos de outros usu=C3=A1rios. + +Quando ``CONFIG_USER_NS`` est=C3=A1 definido, o kernel tamb=C3=A9m permite= que usu=C3=A1rios +sem privil=C3=A9gios criem seu pr=C3=B3prio namespace de usu=C3=A1rio, no = qual possuem todas as +capacidades, mas com algumas restri=C3=A7=C3=B5es (eles n=C3=A3o podem rea= lizar a=C3=A7=C3=B5es que +tenham impacto no namespace de usu=C3=A1rio inicial, como alterar a hora, = carregar +m=C3=B3dulos ou montar dispositivos de bloco). Consulte ``user_namespaces(= 7)`` para +obter mais detalhes; as possibilidades dos namespaces de usu=C3=A1rio n=C3= =A3o s=C3=A3o +abordadas neste documento. + +O kernel tamb=C3=A9m oferece diversos recursos de solu=C3=A7=C3=A3o de pro= blemas e depura=C3=A7=C3=A3o, +os quais podem constituir vetores de ataque quando caem em m=C3=A3os errad= as. Embora +alguns deles tenham sido projetados para serem acess=C3=ADveis a usu=C3=A1= rios locais +comuns com baixo risco (por exemplo, logs do kernel via ``/dev/kmsg``), al= guns +exporiam informa=C3=A7=C3=B5es suficientes para representar um risco na ma= ioria dos casos, +e a decis=C3=A3o de exp=C3=B4-los =C3=A9 de responsabilidade do administra= dor (eventos perf, +rastreamentos), e outros n=C3=A3o foram projetados para serem acessados po= r usu=C3=A1rios +sem privil=C3=A9gios (por exemplo, debugfs). O acesso a esses recursos por= um usu=C3=A1rio +que tenha recebido permiss=C3=A3o expl=C3=ADcita de um administrador n=C3= =A3o constitui uma +viola=C3=A7=C3=A3o de seguran=C3=A7a. + +Bugs que permitem violar os princ=C3=ADpios acima constituem brechas de se= guran=C3=A7a. +No entanto, bugs que permitem uma viola=C3=A7=C3=A3o somente ap=C3=B3s out= ra j=C3=A1 ter sido +alcan=C3=A7ada s=C3=A3o apenas pontos fracos. O kernel aplica uma s=C3=A9r= ie de medidas de +autoprote=C3=A7=C3=A3o cujo objetivo =C3=A9 evitar que um limite de segura= n=C3=A7a seja ultrapassado +quando certas classes de bugs s=C3=A3o encontradas, mas uma falha nessas p= rote=C3=A7=C3=B5es +adicionais n=C3=A3o constitui, por si s=C3=B3, uma vulnerabilidade. + +Quais classes de problemas n=C3=A3o s=C3=A3o consideradas vulnerabilidades +---------------------------------------------------------------- + +No modelo de amea=C3=A7as do kernel do Linux, as seguintes classes de prob= lemas +**N=C3=83O** s=C3=A3o consideradas vulnerabilidades do kernel do Linux. No= entanto, +quando se acredita que o kernel poderia ser melhor, eles devem ser relatad= os, +para que possam ser analisados e corrigidos sempre que razoavelmente poss= =C3=ADvel, +mas ser=C3=A3o tratados como qualquer bug comum: + +* **Configura=C3=A7=C3=A3o**: + + * kernels desatualizados e, particularmente, ramos em fim de vida =C3=BA= til est=C3=A3o + fora do escopo do modelo de amea=C3=A7as do kernel: os administradores= s=C3=A3o + respons=C3=A1veis por manter seus sistemas atualizados. Para que um bu= g seja + qualificado como uma vulnerabilidade, deve ser demonstrado que ele afe= ta + vers=C3=B5es mantidas ativamente. + + * n=C3=ADvel de compila=C3=A7=C3=A3o: altera=C3=A7=C3=B5es na configura= =C3=A7=C3=A3o do kernel que estejam + explicitamente documentadas como redutoras do n=C3=ADvel de seguran=C3= =A7a (por + exemplo, ``CONFIG_NOMMU``), ou destinadas apenas a desenvolvedores. + + * n=C3=ADvel do sistema operacional: altera=C3=A7=C3=B5es nos par=C3=A2m= etros da linha de comando, + sysctls, permiss=C3=B5es do sistema de arquivos, capacidades do usu=C3= =A1rio, e + exposi=C3=A7=C3=A3o de interfaces privilegiadas que aumentem explicita= mente a + exposi=C3=A7=C3=A3o, seja oferecendo acesso n=C3=A3o padr=C3=A3o a usu= =C3=A1rios sem privil=C3=A9gios, + seja reduzindo a capacidade do kernel de aplicar algumas prote=C3=A7= =C3=B5es ou + medidas de mitiga=C3=A7=C3=A3o. Exemplo: acesso de grava=C3=A7=C3=A3o = ao procfs ou ao debugfs. + + * problemas acionados apenas ao usar recursos destinados ao desenvolvime= nto ou + depura=C3=A7=C3=A3o (por exemplo, LOCKDEP, KASAN, FAULT_INJECTION): sa= be-se que esses + recursos introduzem sobrecarga e instabilidade potencial e n=C3=A3o se= destinam + ao uso em produ=C3=A7=C3=A3o. + + * problemas que afetam drivers expostos sob CONFIG_STAGING, bem como rec= ursos + marcados como EXPERIMENTAL na configura=C3=A7=C3=A3o. + + * carregamento de m=C3=B3dulos explicitamente inseguros/quebrados/staging + e, de modo geral, qualquer uso de subsistema marcado como experimental= ou + n=C3=A3o destinado ao uso em produ=C3=A7=C3=A3o. + + * execu=C3=A7=C3=A3o de m=C3=B3dulos fora da =C3=A1rvore ou forks n=C3= =A3o oficiais do kernel; + esses casos devem ser relatados ao fornecedor relevante. + +* **Excesso de privil=C3=A9gios iniciais**: + + * a=C3=A7=C3=B5es realizadas por um usu=C3=A1rio que j=C3=A1 possui os p= rivil=C3=A9gios necess=C3=A1rios + para executar essa a=C3=A7=C3=A3o ou modificar esse estado (por exempl= o, + ``CAP_SYS_ADMIN``, ``CAP_NET_ADMIN``, ``CAP_SYS_RAWIO``, ``CAP_SYS_MOD= ULE``, + sem que nenhum outro limite seja ultrapassado). + + * a=C3=A7=C3=B5es realizadas em um namespace do usu=C3=A1rio que n=C3=A3= o contornam as restri=C3=A7=C3=B5es + impostas ao usu=C3=A1rio inicial (por exemplo, uso de ptrace, envio de= sinais, + uso de recursos, acesso a FS/dispositivo/sysctl/mem=C3=B3ria, v=C3=ADn= culo de rede, + configura=C3=A7=C3=A3o do sistema/rede, etc.). + + * qualquer a=C3=A7=C3=A3o realizada pelo usu=C3=A1rio root no namespace = inicial (por exemplo, + um oops do kernel ao gravar em um dispositivo privilegiado). + +* **Fora do uso em produ=C3=A7=C3=A3o**: + + Isso abrange ataques te=C3=B3ricos/probabil=C3=ADsticos que dependem de = condi=C3=A7=C3=B5es de + laborat=C3=B3rio com ru=C3=ADdo zero no sistema, ou aqueles que exigem u= m n=C3=BAmero + irrealista de tentativas (por exemplo, bilh=C3=B5es de tentativas) que s= eriam + detectadas pelo monitoramento padr=C3=A3o do sistema muito antes do suce= sso, + tais como: + + * previs=C3=A3o de n=C3=BAmeros aleat=C3=B3rios que s=C3=B3 funciona em = um ambiente totalmente + silencioso (como ID de IP, portas TCP ou n=C3=BAmeros de sequ=C3=AAnci= a que s=C3=B3 podem + ser adivinhados em laborat=C3=B3rio). + + * observa=C3=A7=C3=A3o de atividades e vazamentos de informa=C3=A7=C3=B5= es com base em abordagens + probabil=C3=ADsticas que s=C3=A3o suscet=C3=ADveis a ru=C3=ADdo de med= i=C3=A7=C3=A3o e n=C3=A3o s=C3=A3o + realisticamente reproduz=C3=ADveis em um sistema de produ=C3=A7=C3=A3o. + + * problemas que s=C3=B3 podem ser desencadeados por ataques intensos (po= r exemplo, + for=C3=A7a bruta) cujo impacto no sistema torna improv=C3=A1vel ou imp= oss=C3=ADvel + permanecerem indetect=C3=A1veis antes de serem bem-sucedidos (por exem= plo, + consumir toda a mem=C3=B3ria antes de ter sucesso). + + * problemas observados apenas em simuladores de desenvolvimento, emulado= res ou + combina=C3=A7=C3=B5es que n=C3=A3o existem em sistemas reais no moment= o do relato + (problemas envolvendo dezenas de milh=C3=B5es de threads, dezenas de m= ilhares de + CPUs, frequ=C3=AAncias de CPU irrealistas, tamanhos de RAM ou capacida= des de + disco, velocidades de rede). + + * bem como problemas que podem ser acionados a um custo que =C3=A9 orden= s de + magnitude superior aos benef=C3=ADcios esperados (por exemplo, um emul= ador de + teclado totalmente funcional apenas para recuperar 7 bytes n=C3=A3o in= icializados + em uma estrutura, ou um m=C3=A9todo de for=C3=A7a bruta envolvendo mil= h=C3=B5es de + tentativas de conex=C3=A3o para adivinhar um n=C3=BAmero de porta). + +* **Falhas de fortifica=C3=A7=C3=A3o (hardening)**: + + * capacidade de contornar algumas das medidas de fortifica=C3=A7=C3=A3o = do kernel sem um + caminho de explora=C3=A7=C3=A3o demonstr=C3=A1vel (por exemplo, contor= no de ASLR, + sincroniza=C3=A7=C3=A3o de eventos ou sondagem sem consequ=C3=AAncias = demonstr=C3=A1veis). + Trata-se apenas de pontos fracos, n=C3=A3o de vulnerabilidades. + + * falta de verifica=C3=A7=C3=B5es de argumentos e falha ao relatar certo= s erros sem + consequ=C3=AAncias imediatas. + +* **Vazamentos aleat=C3=B3rios de informa=C3=A7=C3=B5es**: + + Isso diz respeito a vazamentos de pequenas partes de dados que simplesme= nte + est=C3=A3o presentes e que n=C3=A3o podem ser escolhidas pelo invasor, o= u que enfrentam + restri=C3=A7=C3=B5es de acesso: + + * preenchimento (padding) de estruturas relatado por chamadas de sistema= ou + outras interfaces. + + * identificadores, dados parciais, strings n=C3=A3o terminadas relatadas= em + mensagens de erro. + + * Vazamentos de endere=C3=A7os/ponteiros de mem=C3=B3ria do kernel n=C3= =A3o constituem um + vetor imediatamente explor=C3=A1vel e n=C3=A3o s=C3=A3o vulnerabilidad= es, embora devam ser + relatados e corrigidos. + +* **Dispositivos e m=C3=ADdias em n=C3=A3o conformidade**: + + Os drivers s=C3=A3o implementados com base em uma especifica=C3=A7=C3=A3= o. Quando um + dispositivo ou m=C3=ADdia de armazenamento viola a especifica=C3=A7=C3= =A3o para a qual o seu + driver foi escrito, o mau comportamento resultante =C3=A9 um bug comum a= ser + corrigido, n=C3=A3o uma vulnerabilidade, a menos que o driver esteja + especificamente documentado como sendo fortificado contra entradas hosti= s. Os + seguintes casos, portanto, n=C3=A3o s=C3=A3o considerados vulnerabilidad= es: + + * bugs desencadeados pela montagem de uma imagem de sistema de arquivos + corrompida ou criada de forma maliciosa: a montagem de um dispositivo = de + bloco =C3=A9 uma opera=C3=A7=C3=A3o privilegiada (veja acima), e o adm= inistrador =C3=A9 + respons=C3=A1vel pela m=C3=ADdia que ele monta. Isso inclui problemas = que s=C3=A3o + resolvidos, mitigados ou detectados pela execu=C3=A7=C3=A3o de uma ver= ifica=C3=A7=C3=A3o de + consist=C3=AAncia do sistema de arquivos (fsck) na imagem antes da mon= tagem. + + * bugs cuja reprodu=C3=A7=C3=A3o requer modifica=C3=A7=C3=A3o de hardwar= e ou emula=C3=A7=C3=A3o, + incluindo dispositivos USB falsos que se passam por outros, ou + dispositivos que relatam valores fora dos seus limites documentados. + +* **Acesso f=C3=ADsico**: + + Problemas que exigem acesso f=C3=ADsico =C3=A0 m=C3=A1quina, modifica=C3= =A7=C3=A3o de hardware ou o uso + de hardware especializado (por exemplo, analisadores l=C3=B3gicos, ferra= mentas de + ataque DMA via PCI-E/Thunderbolt) est=C3=A3o fora do escopo, a menos que= o sistema + esteja explicitamente configurado com tecnologias destinadas a defender = contra + tais ataques (por exemplo, IOMMU). + +* **Regress=C3=B5es funcionais e de desempenho**: + + Qualquer problema que possa ser mitigado pela defini=C3=A7=C3=A3o de per= miss=C3=B5es e + limites adequados n=C3=A3o se qualifica como uma vulnerabilidade. --=20 2.34.1