it-swarm-korea.com

윤리적 인 방식으로 보안 취약점을 공개하는 방법은 무엇입니까?

윤리적 인 방식으로 보안 취약점을 공개하는 방법은 무엇입니까? 이 주제에 대해 다양한 생각의 학교가 있다고 들었습니다. 각각의 장단점을 알고 싶습니다.

75
Olivier Lalonde

개발자에게 비공개로 알리면 문제를 해결할 수 있습니다. 그 후, 취약점을 공개적으로 공개 할 경우 개발자가 문제를 해결할 충분한 시간과 시스템을 업그레이드하기에 충분한 시간이 걸린 사람을 허용해야합니다. 개인적으로, 개발자는 대부분 자신이 발표하지 않고 보안 게시판에 공지를 할 수 있습니다. 최소한 취약점이 수정되었다는 확인을 기다릴 것입니다. 시간이 있고 소스 코드에 액세스 할 수있는 경우 패치를 제공 할 수도 있습니다.

43
VirtuosiMedia

개인적으로 책임있는 공개 는 윤리적 인 관점에서 벗어나는 가장 좋은 방법 인 것 같아 Dan Kaminsky가 DNS 캐시 중독 취약점의 세부 정보를 밝히는 데 효과적이었습니다. 그러나 그것은 모두 당신이 다루고있는 회사 나 그룹 그리고 그것이 영향을 줄 사용자 기반에 크게 의존합니다.

27
Mark Davidson

@VirtuosiMedia는 "책임 공개"의 개요를 잘 보여줍니다.

두 가지 점을 추가하겠습니다.

  • 가능한 경우 공급 업체와 협력하여 공급 업체를 완전히 이해하고 반 구운 패치를 발행하지 않도록하십시오.
  • 공급 업체가 귀하를 무시하거나 무시하는 경우 계속 시도하십시오. 그러나 이들이 취약점이 아니라고 주장하는 경우 계속 진행하십시오. 최대한 크게 그들이 고치겠다고 약속했지만 그렇지 않은 경우, 그들이 저지른 결정적인 일정과 함께 답을 얻으려고 노력하십시오. 어떤 시점에서, 그들이 계속 연기한다면, 결국 당신은 그들에게 당신이 어쨌든 출판 할 것이라고 말하고 실제로 그것들을 고칠 시간을 줄 수 있습니다 (그러나 짧고 제한적입니다).
18
AviD

이것은 복잡한 주제 중 하나입니다. 나는 2 년 전에 TLS 재협상 버그 공개에 관여했으며, "책임"이되기 위해 매우 열심히 노력했지만 결국 우리는 주변의 모든 사람들을 화나게하고 (아마) 지연시키는 데 성공했습니다 수정 사항의 실제 릴리스 벤더 통지가 반드시 나쁘다는 것은 말할 것도없고, 채찍질을하는 것이 정말 쉬워서 좋은 결과를 가져 오거나 나쁘게 만들 수 있습니다.

우리의 경우에는 문제를 해결하기 위해 IETF ( RFC 5746 )의 조치를 취했으며 유출 된 날에 인터넷 초안을 준비했지만 실제 토론 및 결정 작업은 이 솔루션은 약 3 개월이 더 걸렸으며 공개가 이루어질 때까지 본격적으로 시작되지 않았습니다.

어쨌든, 이것은 귀하의 질문에 대한 답변이 아니지만, 내가 알고있는 더 흥미로운 공개 이야기 중 하나입니다. 2010 ShmooCon 기조 연설 에서 그 이야기에 대해 더 많은 것은 문제를 발견 한 Marsh Ray와 함께했습니다.

11
Steve Dispensa

일반적으로 공급 업체의 응답에 따라 다릅니다. 모범 사례는 보안 연구원이 공급 업체에 취약점에 대해 알리고 대화 중에이 취약점의 poc/exploit 게시 조건에 대해 이야기하는 것입니다. 실제로 연구원은이 취약점으로 무엇을 할 것인지 선택합니다 (나중에 게시할지 여부). 그런 다음 공급 업체는 패치 또는 새 제품 버전을 릴리스합니다. 아마도. 그러나 모든 벤더가 그렇게 좋은 것은 아닙니다. 그들 중 일부는 최종 사용자와 연구원에게 알리지 않고 자동으로 버그를 수정하고 일부는 연구원을 무시하는 것을 선호합니다. 다른 사람들은 고소를 시도하기도합니다. 그렇기 때문에 때때로 익명 성이 알려지지 않은 공급 업체와 처음 통신하는 것이 좋습니다.

또한 Google, Mozilla에서 제공하는 버그 바운티 보상 프로그램이 있음을 인정하고 싶습니다. 게다가, 다른 사람들은 취약점을 구입합니다- ZDI , iDefense , SNOsoft 따라서 목록에 또는 타사 회사를 통해 취약성 정보를 게시하여 공급 업체에 직접 알리는 방법에는 최소한 세 가지가 있습니다.

8
anonymous

공개 이슈 트래커가있는 경우 "비공개"또는 "보안"레이블로 버그를 신고 할 수 있는지 확인하십시오.

문제 추적기가 있는지 여부에 관계없이 이메일 [email protected] 회사 이름 을 알려주십시오.

이들이 신속하게 응답하지 않으면 (아래의 Schneier 기사의 "공개 창"참조)보다 광범위하게 공개해야합니다. 보안 전문가/전문가가 숨어있는 메일 링리스트를 찾아 문제의 공급 업체에 문제를보고하는 방법을 문의하십시오. 그들은 조직의 올바른 장소를 소개 할 수 있습니다.

모든 것이 실패하면 Schneier 비트를 읽고 전체 공개가 문제의 일부인지 솔루션의 일부인지 고려하십시오.

Bruce Schneier는 특정 상황에서 "문제의 일부가 아니라 솔루션의 일부"표준에 근거하여 전체 공개 에 대한 논거를 제시합니다. 확실히 읽을만한 가치가 있습니다.

이것은 고전적인 "버그 보안 대 전체 공개"토론입니다. 나는 이전에 Crypto-Gram에서 글을 썼습니다; 다른 사람들도 그것에 대해 썼습니다. 컴퓨터 보안에 미묘한 영향을 미치는 복잡한 문제이며 다시 논의 할 가치가 있습니다.

...

설명 및 개념 증명 코드 모두의이 무료 정보 흐름은 보안 연구에도 필수적입니다. 지난 10 년 동안 컴퓨터 보안에 대한 연구와 개발이 시작되었으며, 그 중 많은 부분이 완전한 공개 운동에 기인 한 것입니다. 좋은 결과와 나쁜 결과를 모두 포함하여 연구 결과를 게시하는 기능은 모든 사람에게 더 나은 보안을 제공합니다. 게시하지 않으면 보안 커뮤니티는 서로의 실수를 배울 수 없습니다. 모든 사람은 눈을 가리고 계속해서 같은 실수를 반복해야합니다. 컴퓨터와 네트워크의 보안을 지속적으로 향상 시키려면 완전한 공개가 필수적입니다.

...

둘째, 공급 업체에 사전 통지를합니다. CERT는이 문제를 극도로 극복하여 공급 업체가 문제를 해결하기 위해 몇 년을 보냈습니다.

...

"문제의 일부가 아닌 솔루션의 일부"라는 메트릭이 마음에 듭니다. 보안 연구는 솔루션의 일부입니다. 벤더가 문제를 해결하도록 설득하는 것이 솔루션의 일부입니다. 파종 두려움은 문제의 일부입니다. 단서없는 십대들에게 공격 도구를 전달하는 것이 문제의 일부입니다.

6
Mike Samuel