▲
GN⁺ 5시간전 | parent | ★ favorite | on: CERT가 dnsmasq의 심각한 보안 취약점 6건에 대한 CVE를 공개한다(lists.thekelleys.org.uk)
Hacker News 의견들

  • C로 작성된 코드를 메모리 안전 언어로 바꾸는 일이 이제 긴급해지는 분기점 같음
    최근 발견되는 취약점의 대부분이 메모리 안전하지 않은 언어와 직접 관련되어 있고, DNS/DHCP 서버를 Rust나 Go로, 가능하면 unsafe 없이 작성할 수 없다고 정당화하기는 매우 어려워 보임

    • https://news.ycombinator.com/item?id=47943499 — coreutils를 새 Rust 구현으로 대체하려다 44개 CVE가 나온 사례가 있음. 공짜 점심은 없음
    • 문제는 언어가 아니라, 이 일을 하려는 인재 부족임
      AI 보안 연구자들은 최소한 뭔가 하기는 함. 모든 걸 Rust로 다시 쓰는 게 그렇게 쉬웠다면, 이런 사고 다음 날 바로 견고한 Rust 대체물이 나왔어야 함
      왜 안 그러냐면, 이런 일을 해도 GitHub 별을 얻기 어렵기 때문임
    • 어쩌면 문제는 동적 메모리를 바라보는 방식일 수 있음
      “최대 크기를 모르니 전부 동적이어야 한다”가 정말 맞는지 의문임. 프로그램이 입력의 허용 가능한 최대 크기를 선언하고, 넘으면 오류를 내거나 링 버퍼를 쓰는 게 정말 세상의 끝은 아님
      크기를 알 수 있다면 그에 맞춰 설계할 수 있음. RAM은 유한한데, 그 안의 모든 계층이 무한한 척 설계되는 이유가 이상함
      Rust로 바꾸는 일은 엄청난 시간 낭비처럼 보이고, 프로그램을 유한한 시스템 자원이라는 현실에 맞게 모델링하지 못하는 근본 문제를 해결하지 못함. 메모리만의 문제도 아님. Chrome이 사용자 기기에 4GB 모델을 올리는 사례도 비슷함
    • 동의하지 않음. 잠재 취약점을 찾는 AI 에이전트 덕분에 보호 장치가 분명히 좋아지고 있음

  • https://xchglabs.com/blog/dnsmasq-five-cves.html

  • OpenWRT가 새 빌드를 냈는지 궁금했는데, 답은 아직 아니고 작업 중임
    https://forum.openwrt.org/t/dnsmasq-set-of-serious-cves/2500...

  • 내 MaraDNS는 AI 지원 보안 감사 시대에 들어서며 꽤 광범위하게 감사를 받았음
    2023년 이후 심각한 보안 버그는 단 하나도 발견되지 않았음 [1]
    감사자들이 찾은 건 “Deadwood가 완전 재귀 모드일 때 특이한 패킷을 받으면 평소보다 자원 해제가 오래 걸린다” [2]거나, “MaraDNS에 포함된 보조 유틸리티가 2022년부터 컴파일도 안 됐는데 $HOME이 50자를 넘을 때만 버퍼 오버플로가 있다” [3] 같은 것뿐임
    깊이 있는 실제 보안 감사를 받는 지금 MaraDNS가 꽤 안전하다는 점이 개인적으로 아주 만족스러움
    [1] https://samboy.github.io/MaraDNS/webpage/security.html
    [2] https://github.com/samboy/MaraDNS/discussions/136
    [3] https://github.com/samboy/MaraDNS/pull/137

    • Lua 5.1을 라이브러리로 만들어 로드하지 않고 Lunacy로 묶어 넣었고, 그것도 2012년 버전이라면 아마 CVE-2014-5461 등에도 영향받을 수 있음
      Lua도 보안 수정이 없었던 건 아님
    • 그래도 MaraDNS는 dnsmasq보다 훨씬 덜 인기 있음
      나도 직접 작성한 라이브러리가 몇 개 있는데, 1991년 이후 심각한 보안 버그가 하나도 발견되지 않았음. 물론 아무도 내 라이브러리를 쓰지 않음
      성과를 깎아내리려는 건 아니지만, 이런 주장은 사용자 기반이 어떤지와 함께 맥락화하는 게 중요함
    • 예전에 DNS 서버를 설정할 때 dnsmasq의 “다 해주는” 방식 대신 MaraDNS를 발견하고 반가웠고, 더 중요하게는 그 뒤로 신경 쓸 일이 없었음
    • 궁금한데 여기서 하려는 말이 뭔지 모르겠음. dnsmasq의 대안이 있다는 건지, 본인 소프트웨어가 somehow “더 낫다”는 건지?
      이 홍보는 dnsmasq 논의에 가치가 거의 없음
      더 많이 쓰이는 소프트웨어일수록 더 많이 검토되고, 더 많은 버그와 경계 사례가 발견됨
    • 잘한 일임. 하지만 2026년에도 핵심 네트워킹 도구를 C 같은 취약한 언어로 계속 작성하고 있다는 건 놀라움

  • 다행히 이 소프트웨어가 거의 업데이트를 받지 않는 수백만 대 기기에서 쓰이는 건 아니겠지

    • 벤더가 “네가 원하는 대로 쓰게 둘 수 없다”고 할 때, 자기 하드웨어를 직접 통제할 수 있는 건 좋은 일임
    • 대부분의 경우 클라이언트가 먼저 Wi-Fi에 인증하거나 이더넷 포트에 물리적으로 꽂지 않으면 패킷을 보내지 않는 기기 위에 있다는 점은 그나마 다행임
    • Y2K26?

  • 꽤 심각함
    “DNS 질의를 할 수 있거나 DNS 응답을 할 수 있는 원격 공격자가 힙에 큰 범위 밖 쓰기를 일으킬 수 있다”
    잘못된 DNS 응답은 “무한 루프를 유발해 dnsmasq가 모든 질의에 응답하지 않게” 만들 수 있음
    악의적인 DHCP 요청은 버퍼 오버플로를 일으킬 수 있음

  • AI 버그 리포트 쓰나미가 모든 프로젝트에 있는 건 아님. 위에서 말했듯 MaraDNS에는 없었음
    djbdns와 tinydns도 없었을 거라고 봄. 있었다면 대대적으로 알렸을 테니까
    어떤 프로젝트는 극도로 인기를 얻고 어떤 프로젝트는 그렇지 않은 이유를 늘 이해하지 못했음
    “공개하기엔 너무 위험하다”는 도구들이 모든 프로젝트를 스캔하되, 문제가 있는 곳에만 선택적으로 연락하는 것 같기도 함. 그래야 자기 도구가 아무것도 찾지 못했다는 사실을 인정할 필요가 없으니까

    • 그런 일은 인기 있는 프로젝트에서 벌어짐

  • dnsmasq를 쓰는 걸 좋아한 적이 없음. 한 도구에 너무 많은 걸 넣은 느낌이었음
    로컬 캐싱 리졸버, DHCP 서버, TFTP/PXE 부팅 설정은 항상 따로 구성하는 쪽을 선호했음

    • 일부에게는 대체하기 어려운 dnsmasq 기능이 몇 가지 있음
      예를 들면 *.example.com 질의를 특정 상위 서버로 보내거나, 피싱 사이트에 NXDOMAIN을 반환하거나, *.example.org로 해석된 모든 IP를 정책 라우팅용 ipset에 추가하는 기능임
      마지막 기능은 BSD에 ipset이 없는데도 FreeBSD에서 동작함. *.example_xyz.com 목록이 매우 클 수 있고, 최근 dnsmasq는 이를 효율적으로 처리한다고 알려져 있음
    • 그런 생각 때문에 오래전에 DNS 호스팅에 MaraDNS를 쓰게 됐음
      10점 만점에 10점이고, 후회 없고, 추천할 만함
    • 동의함. 이건 Linux의 “하는 방식”에도 어긋나는 느낌임
      예를 들어 Opnsense는 dnsmasq의 DHCP 부분만 쓰고 DNS에는 unbound를 쓰는데, 이게 좀 “이상하게” 느껴짐
    • 그게 어느 정도 목적임. dnsmasq는 “작은 라우터 하나 돌리는” 앱을 한 상자에 넣은 것임
      DHCP와 DNS는 연결되어 있고, PXE에는 DHCP 항목이 필요함. 간단한 설정을 하려면 아니면 서로 설정 문법이 다른 데몬 최소 3개를 이어 붙여야 함

  • 이 분야 경험이 더 많은 사람에게 묻고 싶은 초보 질문인데, 왜 이 영역의 소프트웨어가 Erlang 같은 가비지 컬렉션과 동시성을 갖춘 언어 런타임으로 더 많이 작성되지 않는지 궁금함

    • dnsmasq의 최초 릴리스는 2001년이었음. 당시 고성능 네트워크 서버에 현실적으로 쓸 수 있는 언어 목록은 그리 길지 않았고, Erlang은 거기에 없었음
      성능 손실이 너무 컸고, 당시 안정적이었는지 알기 어려운 불투명한 런타임이 있었고, 기여자도 적었고, 대부분의 시스템에 설치되어 있지 않을 의존성 발자국도 컸음
      2015년쯤 프로덕션 시스템에 Erlang을 썼을 때도, 원래 의도된 용도에서 조금 벗어나면 거친 부분이 있었음. Erlang만의 비판은 아니고, 많은 언어와 런타임이 비슷했음
      앞으로 몇 주나 몇 달 동안 계속 타격을 받을 이런 시스템 상당수도 비슷한 배경을 가짐. Linux 커널이 당시 선택할 수 있었던 잠재적 대안은 C++ 정도였음. 보안 문제의 단골인 OpenSSL은 1998년에 시작됐음
      “네트워크 접근이 있는 새 프로젝트를 C로 쓰지 말라”는 말에는 나도 매우 강하게 동의하지만, 1998년으로 돌아가면 어떤 다른 선택지가 현실적이었는지 말하기 어려움
      더 안전한 언어들은 있었지만 C 커뮤니티보다 훨씬 작았고, 안정성을 보장하기도 어려웠음. Java는 나와 있었지만 네트워크 서버의 진지한 후보가 된 정확한 시점은 모르겠고, 대략 2000년대 후반쯤으로 봄. 1999년에 본 Java는 아직 아니었음
      예를 들어 2011년에 비교적 중요하지 않은 용도로 Haskell 네트워크 서버를 운영했는데, 프로덕션 네트워크라면 그리 극단적이지 않았을 조건에서 넘어졌음. 2013년에 같은 코드 기반을 핵심 실행 루프 변경 없이 재사용했더니 약 90% 좋아졌기 때문에 내 코드보다는 Haskell 쪽 문제였다고 봄
      그래도 실제 프로덕션에 넣을 정도는 아니었지만, 최소한 내 코드가 실패한 건 아니라는 점은 보여줬음. Haskell이 2000년대에 존재했더라도 당시 네트워크 서버의 현실적 선택지로 보기 어려웠다는 뜻임
      지금은 예전보다 훨씬 많은 선택지가 있음
    • C에서는 보통 struct를 네트워크 패킷에 직접 매핑할 수 있어서 꽤 쉬움
      다른 언어에서는 그렇게 단순하지 않은 경우가 많음
      물론 더 느리고 더 크다는 점도 있음