PHP 취약점, 아직 실제 공격은 불가능하다
There isn't an easy exploit for this PHP vulnerability
PHP 코어 팀원이 '패치 15분 뒤 익스플로잇이 나올 것'이라 경고하며 공포가 번졌지만, 10시간이 지나도 동작하는 익스플로잇은 없다. GitHub에 올라온 수천 개의 PoC는 대부분 LLM이 만든 가짜이거나, 서버에 이미 LFI 같은 별도 취약점을 심어야 작동하는 실험실용이다. Log4Shell이나 Heartbleed처럼 즉시 봇넷이 퍼지는 상황과는 거리가 멀다.
정말 웃긴 건, 대부분의 'PoC'가 LFI, 즉 로컬 파일 포함에 의존한다는 점이다. 비PHP 식으로 말하면, 그들의 익스플로잇 체인은 서버가 사실상 `eval(read(사용자가 제공한 파일명))`을 실행하도록 요구한다.
HN 토론
374- nallerooth
사이버 보안 분야에서 전문가처럼 들리려는 사람이 이런 주장을 하다니 정말 이상하네요(그 사람이 전문가일 수도 있죠, 누군지 전혀 모르겠지만). 익스플로잇을 제대로 사용하기 어렵다 해도, 이를 시도하는 그룹이 없는 건 아닙니다.
이 문제를 진지하게 보는 사람이라면 작동하는 PoC가 PHP 보안팀에 보고되었다는 사실을 고려할 겁니다. 그들은 취약점을 확인했고, 2개의 CVE를 보고하고 공식 패치 릴리스 전에 Linux 배포판에 패치를 푸시하면서 심각성에 대해 엄청난 소란을 피웠죠.
이 글의 메시지가 대체 무엇인지 이해하려고 머릿속에서 전체를 뒤집어 보니, 메시지는 기본적으로 "서버를 업그레이드할 필요 없다"는 것이더군요. 이는 작동하는 익스플로잇을 가진 사람이 할 법한 말입니다. 아니면 그냥 인터넷의 소음일 뿐이거나요.
- hn773746483
소셜 미디어와 "사이버 보안 전문가"들이 여기서 큰 역할을 했습니다. "EU, 이것은 긴급 취약점이라고 발표" 같은 것부터 일본 총리가 야간에 공익 광고를 하는 것까지요. 그들은 최초 권고에 대한 "전문가들"의 소셜 미디어 게시물을 인용하면서, 바로 그 소위 전문가들은 구글 검색 AI 출력을 완화 전략으로 공유합니다. 이 조직이나 기관 중 어느 곳도 권고문과 소셜 미디어에 있던 것 외에는 아무런 세부 정보가 없었습니다. (예: "CVSS 10, 이건 심각해!!")
제게는 broadpwn과 더 비슷해 보입니다. 기술적으로 심각하고 범위가 넓지만(수백만 대의 아이폰), 결코 만능 PWN 버튼이 되지는 않을 겁니다.
AI 시대에도 이것이 나중에 Eternalblue처럼 무기화되지는 않을 것 같습니다... 하지만 저는 팔로워 15000명을 가진 소셜 미디어 사이버 보안 전문가가 아니니, 제 말을 액면 그대로 받아들이지 마세요 ;)
- tibbar
두 가지가 동시에 사실일 수 있습니다: 실제로 악용 가능한 CVE 10이며, LLM이 속임수를 부리지 않도록 좋은 하네스 + 검증 프로세스가 필요할 정도로 구성하기 어렵다는 것. 즉, 익스플로잇 구성이 쉽지 않을 수는 있지만, 원문 작성자가 암시한 인위적인 설정이 실제로 필요한 것은 아닙니다.
> 우리가 입증한 것
> WordPress, Drupal, Joomla에서의 인증 전 RCE
- nemothekid
저에게 이상했던 점은 취약점이 실제로 어떻게 작동하는지에 대한 분석 글이 전혀 없었다는 것입니다. 정말 많은 사람들이 "Claude가 버그를 찾았고, Claude가 위험하다고 말한다"고만 했지, 실제로 얼마나 악용 가능한지 아무도 검증하지 않은 것 같습니다. 무시할 만하다는 건 아니지만, Heartbleed(익스플로잇을 직접 작성해야 했던)에 비하면 활성 PoC가 훨씬 적습니다.
- apexalpha
이건 분명히 악용 가능했습니다. 작동하지 않는 PoC 1000개가 있다고 해서 작동하는 하나가 무효가 되지는 않습니다.
물론 순정 설치에서는 아닐 수도 있지만, 대부분의 사람들은 PHP를 직접 설치하지 않고 미리 만들어진 컨테이너나 내부적으로 PHP를 사용하는 플랫폼을 씁니다.
어제 저는 더 이상 보안에 자신이 없었고, 제 데이터베이스의 데이터는 몇 시간 동안 오프라인 상태를 감수할 만큼 중요했습니다.
- kgeist
오늘 GitHub에서 PoC 두 개를 실행해 봤습니다. 하나는 실제로 Local File Inclusion(LFI)이 이미 존재해야 했고(즉, 단계만 추가된 LFI일 뿐), 다른 하나는 약간의 수정 없이는 그대로 작동하지 않았습니다(같은 Docker 이미지 등을 사용했는데도요). 두 번째 PoC는 결국 실제 stale write 버그를 유발했지만, 실제 RCE를 입증하지는 않았고 그저 stale write를 일으켰을 뿐입니다. 그러다 궁금해졌습니다. PHP 런타임에 메모리 손상 버그가 생긴 게 이번이 처음일까? 그럴 리 없습니다(몇 년 전 고부하 상태에서 opcache 버그로 인해 프로덕션에서 무작위 충돌이 발생했던 기억이 납니다). 그리고 PHP 런타임의 첫 번째 메모리 손상 버그가 아니라면, 왜 수년 만에 최악의 취약점이라고 선언되는 걸까요?
- nickysielicki
Wordpress, joomla, drupal의 Docker 이미지 모두 악용 가능했습니다.
- rectang
https://news.ycombinator.com/item?id=50182987 에서 논의된 "오늘의 PHP 보안 릴리스와 PHP 보안을 강화하는 방법"에 따르면:
* 한 CVE와 관련해 "애플리케이션 수준 코드 경로를 통해 PHP-FPM에서 원격 코드 실행도 확인되었다."
* 다른 CVE와 관련해 "use-after-free와 워커 크래시가 확인되었으며, 보고자는 mod_php와 함께 Apache에서 실행되는 실제 애플리케이션을 대상으로 원격 코드 실행을 입증했다."
이러한 익스플로잇이 존재하므로, LLM이 곧 이를 복제할 것으로 예상합니다.
- easterncalculus
돌아다니는 가짜 익스플로잇에 관한 LiveOverflow 관련 영상 https://www.youtube.com/watch?v=7CiZmq2llDg
그렇긴 하지만, 원문 작성자는 기본적으로 헛소리입니다. 이건 분명히 악용 가능하며, 사람들은 플랫폼과 ABI를 가정하고 인터넷 전반에 뿌릴 것이고, 특히 mod_php를 기대할 겁니다.
- 0x1F8B
이 사람이 악용 불가능하다고 그렇게 확신한다면, 악용 가능한 버전의 PHP가 실행되는 아주 기본적인 nginx + php-fpm 서버를 세우고 사람들에게 악용해 보라고 초대해야 합니다.