그누보드 extract() 위험성 및 개발자 주의 필요 > 자유게시판

자유게시판

그누보드 extract() 위험성 및 개발자 주의 필요 정보

그누보드 extract() 위험성 및 개발자 주의 필요

본문

변수 사용시 초기화 또는 검증을 하지 않고 사용시

초기화하지않은 변수는 그누보드 자체에서 GET, POST 요청 값으로 초기 값이 정해져 공격자가 이를 악용할 수 있습니다. PHP 공식 매뉴얼에서도 경고하고 있는 위험을 그누보드에서 이 경고에도 불구하고 잘못된 방법으로 사용하고있기 때문입니다.

 

그누보드는 extract() 함수로 GET, POST, SERVER 값을 글로벌 변수로 풀어놓기 때문에 변수 초기화를하지 않고 사용시 악의적인 공격이 가능해집니다.

 

그누보드 자체에서도 이런 문제로인해 보안취약점이 아직까지도 같은 방식의 문제가 계속 발견되고있죠.

 

하지만 이 보안패치는 그누보드 자체에서만 문제가 고쳐질뿐이고 스킨이나 플러그인, 빌더 등 서드파티에서는 이 문제가 계속될수있습니다.

 

보안 문제뿐만 아니라 변수초기화를하지 않고 사용했을 때 사용자 입력값으로인해 마치 정상적으로 변수가 초기화된것처럼 동작할수있기 때문에 오동작 가능성도 있습니다.

 

extract 함수를 이용한 그누보드의 방식은 일어나지 않아도 될 보안 문제를 일부러 만들어 놓은 것과 다름이 없습니다. 이는 과장이 아니며 조금 편하려고 해놓은 것이라 추측되는데 이로인해 십여년이 넘게 보안문제를 만들어오는 원인이 된것이 사실입니다.

 

아마도 편의상의 목적이 이제는 뺄수도 없는 상황이라 문제를 안고가는것같은데 최악의 선택이 되고 말았죠. 그누보드 자체 뿐만 아니라 스킨, 플러그인 등의 제작자와 사용자를 무방비로 위험에 노출되게 만들어버렸습니다.

 

그누보드의 코드가 낡거나 모던PHP를 따라가지 못한다고 계속 이야기가 나오는 이유 중 하나는 단순히 개발 트렌드의 문제나 코드가 이쁘지 않아서가 아닙니다.

이러한 낡거나 나쁜 코드가 곳곳에 있기 때문이고 혹시나 잘못 될까봐.. 혹은 이 문제를 고치면 분명 영향을 받을수밖에 없기 때문에 알면서도 고치지 않고 있기 때문입니다.

 

스킨, 플러그인 등 각 개발자는 자신이 만든 것들에 대해 보안 점검을 해보시기 바라며, 이를 사용하시는 분들도 사용에 주의하시기 바랍니다.

제작의뢰 또한 이러한 보안문제를 잘인식하고 대응이 가능한 개발자에게 맡기시기 바랍니다.

 

추천
4

베스트댓글

집 지붕에서 물이 새는데 어디서 물이 새는지 아니 피해갈수 있지 않느냐, 혹은 샤워까지 할수 있다고 좋아하는 격입니다. 취약점은 장점이 아닙니다.

호환성 때문에라도 당장은 유지해야겠지만 이후 반드시 수정이 되어야 할 부분입니다.

댓글 21개

그누로 개발하는 사람 중에 그걸 모르는 사람은 거의 없습니다. 별로 특별한 일도 아니구요.^^
그런 점을 알고도 그누를 쓰는 건 리스크를 감수하고도 더 매력적인 부분이 그누에는 있다고 판단하는 사람이 생각보다 많다는 것이겠지요.
그것도 아주 많이요.
모르는 "사람"이야 많겠지만 php 내지는 그누를 자주 사용하는 "개발자"가 그걸 모른다는 건 좀 이상한 일 같은데요?
취약점을 알면서도 편하니까 쓰는 거지요.^^
뭐.. 저도 그 이유를 찾으면서 '편해서 그러지 않았을까'라는 생각을 했지만 사실 그 편하다는 것도 $var VS $_GET['var'] 이 차이예요. 정말 보안이나 오동작을 유발해도 감당할만큼 편한거 맞나요...?
그걸 바꾸면 이전에 만들었던 그로부터 근거한 모든 프로그램과 홈페이지를 전부 수정해야 합니다. 단순하게 변수 하나 고치고 안 고치고의 문제가 아니거든요.
그런 면에서 제 입장에서는
정말 보안이나 오동작을 유발해도 감당할만큼 편한 것이 맞습니다.^^
집 지붕에서 물이 새는데 어디서 물이 새는지 아니 피해갈수 있지 않느냐, 혹은 샤워까지 할수 있다고 좋아하는 격입니다. 취약점은 장점이 아닙니다.

호환성 때문에라도 당장은 유지해야겠지만 이후 반드시 수정이 되어야 할 부분입니다.
댓글에도 적었지만 지금 그걸 바꿨다간 해당 동작에 의존하는 수많은 자료가 오동작할 것입니다. 수정된다면 호환성을 깨는 버전인 다음 메이저 버전업때 이루어져야겠죠.

또한 저에게는 코드를 수정할 어떠한 의무도 없습니다. 수정을 요구하신다면 정중히 거절하겠습니다.

저는 취약점을 좋아한다고 말한 적이 없습니다.
때문에 지붕에 물이 새어서 다른 걸 할 수 있다고 "좋아한다."라고 표현하신 것은 상황에 맞지 않다고 봅니다.

YJSoft 님께서 제가 요청한 수정 코드 배포에 응답해야 할 어떠한 의무도 없듯이 리자님이나 냑 운영진도 다음 메이저버전으로의 업뎃시 YJSoft 님이 제시하신 점을 수정해야 할 어떠한 의무도 없습니다.
아니 그 이전에 메이저버전으로 업뎃해야 할 의무 자체도 없으신 거구요.
반대 측면에서 볼 때는 업뎃을 할 때 그 내용이 어떠한 것인지는 한마디로 리자님 마음대로이고 우리는 "반드시" 이런 걸 하라고 요구할 어떤 권리도 갖고 있지 않습니다.

그누의 취약점 문제는 비유하자면 현재 우리의 택배 문제와 비슷하다고 봅니다.
현재 택배 시스템은 집주인이 있거나 없거나 상관없이 아파트의 경우 대문 앞에 물건을 놓고 그냥 다음 배달을 진행하는 시스템입니다. 한 마디로 무진장 보안에 허술하고 절도나 분실의 위험에 고스란히 노출되어 있죠.
그렇다고 집주인이 나타날 때까지 배달하는 분이 마냥 기다리거나 아니면 주인이 없을 때는 도로 가져가서 나중에 주인이 받을 때까지 재배달하는 시스템으로 전환한다면 어떻게 될까요?
아마 대부분의 고객들이나 배달하는 분 모두 절도나 분실의 위험이 있을지언정 예전 방식으로 해 달라고 아우성일 것입니다.

가장 처음으로 돌아가 볼게요. 이 문제는 그누를 가지고 개발을 해 본 사람이라면 거의 누구나가 알고 있는 문제입니다. 당연히 저도 그렇구요.
그럼에도 불구하고 댓글을 삐딱하게 달은 이유는...

https://sir.kr/cm_free/1628364

위 링크 댓글을 보시면 "세상에 10년 전에 이미 문제를 알고 있었는데도 중간에 농담 따먹기하다가 그냥 방치됐군요." 라는 이 멘트가 웹 에티켓상 너무 무례하다는 생각에서 그런 것입니다.
"농담따먹기하다 방치했다." 이게 얼마나 통렬한 우롱이나 조소의 표현인지, 이 글을 읽는 운영진이 어떤 느낌일지 생각해 보셨는지요?
이런 언사는 보안 취약점을 따지기 이전의 기본 예의에 대한 문제입니다.
코드에 대한 문제는 님 생각에 대해 많은 부분에서 동의합니다만 제가 달은 삐딱한 댓글의 이유는 코드 문제 때문이 아니라는 점을 알아주셨으면 합니다.
해당 댓글에서나 DM으로 예의를 지키라고 말씀해주셨으면 표현을 고쳤을텐데요. 보시는 분들에게 불쾌감을 주어 죄송합니다. (수정하려니 수정이 안되네요)

"그누를 가지고 개발을 해 본 사람이라면 거의 누구나가 알고 있는 문제"라고 하셨는데...
https://github.com/gnuboard/gnuboard5/commit/ab5fb4815d7406e83dc84998f22e8ec511f6aa8b
그누보드 개발자분들 마저도 KISA를 통한 보안취약점 제보를 통해서 문제를 고치셨네요.
로그보니 대략 2013년에 관련 기능이 추가되고 아마 문제 발현은 코드 변화에 따라 그때 발생한 문제이지는 않을수도 있겠으나 최대 5~6년만에 고쳐진 문제같군요.

https://github.com/gnuboard/gnuboard5/commit/fdd2d30f4e83119419e9f5d9065ca13a93632422
지난 달에 수정된 이것 또한 POST 전송이 이뤄진 후의 페이지라서 쉽게 공격은 안되겠지만 변수 선언을 안하고 바로 echo로 그대로 출력해버린 실수로 CSRF 공격 가능성이 있는 문제죠.

$_GET으로 받은 변수가 아님에도 불구하고 단순히 변수 미선언 경고에 그치지 않고 이렇게 전역변수가 오염되어버리는건 문제입니다.
제가 단 댓글도 아닌데 왜 그걸 제가 생각해야 하는지 모르겠습니다.비타주리님이야말로 무례한 댓글을 달고 계신건 아닌지 다시한번 생각해 보셔야 할것 같습니다.
제가 무슨 무례를 범했다는 건지 모르겠네요?

1. 그누 개발자 중 일반변수 겟변수 포스트변수를 한꺼번에 털어 넣는 걸 모르는 사람은 아마 거의 없을 것이다. 그럼에도 불구하고 지금 상황에서는 그걸 쓸 수 밖에는 없다. 라는 걸 에둘러 표현했습니다.

-------------------

2. 제 이 글에 YJSoft 님은 이런 댓글을 달았습니다.
지붕에 물 새는 걸 좋아하고 취약점을 장점으로 생각하서는 안 된다.
그런데...
1) 제가 지붕에 물 새는 걸 좋아한다고 얘기한 적이 있습니까?
2) 제가 취약점이 곧 장점이라고 얘기한 적이 있습니까?

하지도 않은 말을 가지고 제가 그런 얘기를 한 것처럼 말씀하시는 건 오히려 그게 무례가 아닌가요?
하지도 않은 말을 가지고 제가 그런 얘기를 한 것처럼 말씀하시는 건 오히려 그게 무례가 아닌가요?

--------------------

3. 그래서 그렇게 그누의 안위가 걱정되시면 실력좋으신 YJSoft 님이 통 큰 배포를 하라고 말한 것이구요.

--------------------

4. YJSoft 님은 수정코드를 배포할 의무가 없다고 "정중히" 거절한다고 하셨는데 유감스럽게도 저는 전혀 정중함을 느끼지 못했습니다. 나는 정중하게 무언가를 했는데 상대방이 정중함을 느끼지 못했다면 그건 정중이 아닙니다.

-------------------

5. YJSoft 님이 수정코드를 배포할 의무가 없듯이 그누의 운영진도 수정코드를 배포할 의무가 없다고 제가 말씀드린 것이구요.

처음 1번을 에둘러 삐딱하게 표현한것에 대해 이유를 설명을 했습니다.
1번 댓글은 YJSoft 님을 대상으로 한 것도 아닌 셈이죠?

--------------------

제게 무례를 논하시려면 지붕과 취약점 장점에 관련해서 제가 하지도 않은 말을 근거로 날카로운 댓글을 달으신 본인의 무례부터 먼저 생각하셨으면 좋겠습니다.
이 이상 댓글 달리면 글 주제와 무관한 분쟁이 될것 같으니 댓글은 이것이외 그만 달겠습니다. 요점은, 아무리 편리하다 해도 취약점을 방치해서는 안된다는 것입니다. 그걸 설명하기 위해 비유를 쓴건데 그거 하나로 이렇게까지 과민반응하실 이유는 없어보이네요.

저는 요점이나 결론이 중요하지 않고 과정이 더 중요합니다.
지붕과 취약점 장점에 관련해서 제가 하지도 않은 말을 가지고 과민반응을 보인 건 YJSoft 님이시구요.
제가 주장하지도 않은 것을 단순한 비유인데 왜 날카롭게 반응하느냐는 식이라면 세상에서의 모든 과도한 언사는 비유로 정당화될 수 있습니다.
어차피 댓글을 달지 않으시겠다고 말씀하셨으니 저도 그리 알겠습니다.
프로그래밍 언어 배울 가장 먼저 배우는 것
변수는 사용하기 전에 반드시 선언(초기화)해야 한다.

그누보느도 이 부분 때문에 많이 고생?했었죠.
php위원회에서
3년전에 php 9부터 언어차원에서
변수를 초기화하지않으면 못쓰게하기로
결정했습니다. (fatal error)

그누보드도 php9를 지원하려면 바꾸겠지요.
전체 189,490 |RSS
자유게시판 내용 검색

회원로그인

(주)에스아이알소프트 / 대표:홍석명 / (06211) 서울특별시 강남구 역삼동 707-34 한신인터밸리24 서관 1404호 / E-Mail: admin@sir.kr
사업자등록번호: 217-81-36347 / 통신판매업신고번호:2014-서울강남-02098호 / 개인정보보호책임자:김민섭(minsup@sir.kr)
© SIR SOFT