요며칠사이에 큰 논란이 되었던 그누보드 세션취약점 10년만에 패치!!
https://sir.kr/g5_pds/6462
data 폴더에 두지않고 신규설치시 라이믹스처럼 PHP 기본세션 경로에 둡니다.
htaccess 도 추가되어 403으로 접근 금지되었습니다!
-
흠.. 공식사이트는 패치가 안된것 같네요. -
제가 경험해본 그누보드의 경우 코어에 해당하는 부분을 수정한 경우가 많아서 업데이트가 떠도 패치를 안하는, 못하는 경우가 태반이더군요.
뭘 수정해놨는지 일일이 파악하는 것 자체가 쉬운일이 아니니까요.
물론 제 경험은 의뢰를 받아서 하는 것이라 제작만 하고 유지관리는 안하는 경우가 대부분이라는 것도 한 몫하겠지만요.
뭐 업데이트를 안한다는 점은 xe도 비슷했지만요. 코어 수정을 한 경우는 상대적으로 적다보니 업데이트를 할려고 하면 도전해볼수는 있다는 점에서 차이가 있네요. -
그나마 이번문제는 .htaccess 작성만으로도 해결가능하긴 합니다. ./data/sessions 폴더 접근만 차단하면 되는거라서요. 물론 제일 좋은건 세션폴더 지정을 삭제하는것입니다. -
훅 적용 가능해진 후로는 코어 수정을 딱히 안해도 되니 업데이트에도 크게 문제가 없습니다. -
그누보드도 훅이 적용가능해 진 것인가요? 오호!
그 이후 새로 만들어지고, 그것을 적용한 곳이라면 덮어씌우기만 하면 되니 업데이트가 쉽겠지만...
아닌 사이트가 너무나 많더군요. 10군데 의뢰 받으면 8군데는 코어를 막 수정해버린....-0;;;;
물론 이건 제 경험에만 의존한거라 데이터가 적지만 무시할수 없는 수준인거죠. -
이렇게 간단한 것을...
-
그노보드 오래 사용하신분은 대부분 수정해서 사용하고 있을겁니다. 꽤 오래된 버그라서….^^
-
유저들도 인지하고 있고.. 개발자도 인지하고 있는데.. 이제서야ㅠㅠ 부랴부랴 패치는 좀;; 선넘었네요..
매번 패치가 없엇던 프로그램이 아니였을텐데.. 그건 좀 아쉽네요 ㅎㅎ -
이해는 합니다. 모든 오픈소스들의 맹점 이지요.
그나마 계속 패치 해주는것만도 감사하게 사용중 입니다…^^ -
패치해주는데 안해주는것을 그저 그려려니 받아들이고 넘어간다면 그것또한 오픈소스에 안맞다고 생각해요.
오픈소스라고 하면 누군가 고칠 수 있고 방안을 제시할 수 있으면 언제든지 참여해서 코드방향성 및 제시를 해주고, 메인테이너역시 그에 맞는 상응하는 반응을 보여줘야 발전이 빠르지요.
단순히 이제 그나마 패치를 해주는것에 감사하기보단, 어떤 CMS던 발전을 하고 싶다면 쓴소리를 가끔 낼 줄은 알아야 하지 않을까 합니다.
결국은 유저들이 많이 사용하는 CMS일수록 그에 대응이 없을때 상응하는 대응은 꼭 필요합니다.
이건 라이믹스도 마찬가지이고요 ㅎㅎ -
그래서 버그신고 게시판이 존재하죠….^^
공개적으로 취약점에 대해서 글을 적고 비난 하는것 보다는 버그신고를 통해서 가능 하다면 해결책까지 알려 주는게 바람직하다 생각이 드네요.
아마도 그누보드 측에서도 낡고 오래된 그누보드 코드를 수정하기 위해 지금도 고생하고 있을겁니다.
조만간 새로운 그누보드6 이 나온다는 카더라 정보가 있네요…^^ -
?
저도 제가 발견한 취약점은 버그신고 게시판에 비공개로 남겼습니다.
버그신고 게시판 가보시면 세션고정 취약점 문제 폰으로 타이핑힘든데 나름대로 정성을 담아 썼습니다. 해결 방안도 나름 적었습니다(내용 확인은 못하시겠지만요).
공개적으로 비난한건 이미 다른 사람이 공개한 깃헙 이슈로 취약점이 한달이상 방치되어있던 상태였습니다.
근데 지난 이슈들 보니 보안취약점이 깃헙 이슈에 다 올라오네요. -
?
근데 그누보드6이 벌써 나올까요?
그누보드6에 대한 것도 냑이 아니라 회원중 한분이 계속 혼자서 이슈 만들어 고민하고 제안하던 것이고, 가칭 그누보드M이라는 이름으로 진행되던것도 엎고 몇가지 기능에 그누5에 적용했더라구요
친분이 있어서 따로 들은신게있는지 모르겠지만 공개된 내용중에는 냑에서 진행하고 있는 모습은 안보이더라고요. -
?
제 생각에는 지한님 처럼 누군가 자꾸 이야기 안하면 이번취약점도 묻혔을겁니다
왜냐면 10년동안 그대로인게 왜 갑자기 패치되었을까요?? 계속 떠들어대서 심각성이 인지된게 아닐까요?
그리고 냑은 개인도 아니고 회사인데 그정도 이야기 하는것은 괜찮다고 봅니다 -
그런데, PHP 기본세션 경로로 동작하게 패치를 해버려서,
제가 다른 글에서 언급한 세션공유 취약점이 생겨버린 관계로, 이 후에 5.5.7.4 추가 보안패치를 했더라구요.
추가 보안패치 코드를 보니, 세션에 회원 가입일을 기록하고, 이 값을 비교하는 코드를 추가했더군요.
제가 세션 다운로드 취약점을 패치했다면, 사이트의 고유정보를 섞어서 save_path에 postfix를 추가하여 경로를 추정할 수 없게 한줄 패치했을것 같아요. -
?
방법은 많으니 어떤 선택을 하든 해결을하면 됐긴한데 너무 주먹구구식으로 하네요.
세션고정취약점 고친것도 PHP 7이상 함수를 사용해서 그누보드 지원사양에서 오류나고요.
더구나 이 문제 해결을 위해 토큰을 생성할 문자열에 그누보드 버전을 넣어놔서 사용자들이 버전 업데이트할때마다 모든 접속자의 정상적인 세션을 만료시키게 만들어버렸습니다.개발환경 설정을 어떻게 했는지 수정한 파일들 줄바꿈 문자열도 다 바꿔버리고 인코딩도 깨먹고 아주 난리네요.
-
?
그누보드 개발진이 직접 차단한건가요?ㄷㄷ
-
소스가 공개되어 있고, 버전도 쉽게 유추할 수 있고, 흔히 사용하는 웹호스팅이라면 설치 경로 등 "고유정보"라고 할 만한 것들도 대부분 뻔하기 때문에 경로를 찾는 것이 어렵지는 않을 겁니다. 랜덤으로 생성하여 설정 파일에 저장해 놓은 비밀키를 사용한다면 몰라도요. 커스텀 세션 핸들러를 사용한다면 sess_ 부분도 변경할 수 있고요.
어쨌든 session.save_path 기본값은 서버 관리자의 영역입니다. CMS에서 아무리 땜빵하려고 해도 안전하지 않은 서버 세팅을 커버하는 데는 명백한 한계가 있고, 패치 전처럼 어설프게 보완하려고 하다가는 오히려 더 큰 문제가 생기곤 하지요. 서로 다른 계정의 세션이 공유되는 정신나간 호스팅이 있다면 그 업체를 공개적으로 망신주거나, 사고가 터져서 스스로 망하기를 기다리는 편이 CMS에서 반쪽짜리 패치를 계속 시도하는 것보다 훨씬 나을 것 같습니다. CMS에서는 기본값을 존중하거나, 그냥 .htaccess로 막거나, 라엘님이 다른 사이트에 쓰신 글처럼 막는 법을 가르쳐 주거나, 어느 하나만 해도 자기 책임은 다 한 거고요.
XE가 호스팅 업체들에게 "PHP 5.3 지원하든지 망하든지!"라고 엄포를 놓을 수 있었던 시절이 그립네요. CMS 개발자들이 왜 남의 똥까지 닦아 줘야 하는 건지... -
?
?
네? 해당코드 보니까
if(function_exists('random_bytes')){
return bin2hex(random_bytes($length));
}
$characters = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz';
$characters_length = strlen($characters);
$output = '';
for ($i = 0; $i < $length; $i++)
$output .= $characters[rand(0, $characters_length - 1)];
function_exists 로 php7.0 이랑 해당 익스텐션 설치여부에 대응되어있던데요?? -
?
?
댓글을 이제봤네요.
대응없이 배포했다가 오류보고받고 고쳐서 다시 배포했어요.https://github.com/gnuboard/gnuboard5/commit/62ebce3d9c3b2c9a9b613dcd86b2c775d857a5b7
