우부투서버14.04에서 nginx와 php-fpm으로 웹서버를 돌리고 있는 중입니다.
openssl의 heartbleed 버그 때문에 보안에 문제가 있다고 해서 살펴봤거든요.
nginx는 openssl 최신버전(1.0.1h) 소스를 같이 컴파일해서 문제가 없더군요.
그런데 php-fpm은 apt-get으로 설치한 libssl을 사용하는데, 이게 1.0.1f 버전이네요.
heartbleed 버그 문제 있다는 바로 그 버전.
보니까 현재 제 서버에는 libssl이 2가지 버전이 설치되어 있더라구요.
-
1.0.1f 버전 : /lib/x86_64-linux-gnu/libssl.so.1.0.0 <= apt-get으로 설치한 것. php-fpm이 사용 중.
-
1.0.1h 버전 : /usr/lib/libssl.so.1.0.0 <= openssl 소스 컴파일해서 설치한 것. nginx에 포함됨.
일단 1.0.1f 버전 libssl.so.1.0.0 를 1.0.1h 버전으로 교체하려고 시도해봤습니다.
1.0.1h 버전으로 파일 링크도 걸어보고 직접 복사도 해봤는데
php-fpm이 버전 정보를 알 수 없다고 받아들이질 않고 실행도 안되버리네요.
php-fpm도 nginx처럼 최신버전 소스를 가져다가 컴파일 설치했거든요.
이러면 php-fpm을 새로 컴파일 설치해야 하는 건가요?
- 한편으로 궁금한 것이 그동안 apt-get upgrade를 꾸준히 해줬거든요.
그러면 1.0.1f 버전이라도 ubuntu에서 버그패치한 버전으로 자동으로 upgrade되는 거 아닐까요?
자세히는 모르지만 centos던가 그런 식으로 heartbleed 버그패치를 했다고 들은 것 같네요.
라이브러리 복사든 링크든 변경하신 다음에 데몬 재시작 혹은 시스템 리붓 하셨나요?
라이브러리(so 파일)는 한번 참조하면 메모리에 로드하기 때문에 시스템 상의 파일 변경이 바로 반영되지는 않습니다.
libssl을 바꾸면 php-fpm이 제대로 실행되지 않는다고 적었거든요.
메모리에 올렸던 걸 읽는다면 이러지 않겠죠.
[quote="pdf0710":1dh9jhu9]
일단 1.0.1f 버전 libssl.so.1.0.0 를 1.0.1h 버전으로 교체하려고 시도해봤습니다.
1.0.1h 버전으로 파일 링크도 걸어보고 직접 복사도 해봤는데
php-fpm이 버전 정보를 알 수 없다고 받아들이질 않고 실행도 안되버리네요.
[/quote:1dh9jhu9]
Minor version number까지 같아서 file 이름까지 같은 library를 교체했는데 "버전 정보 어쩌구" 하는 error message를 준다는 것이 이해가 안되네요. 혹시 libcrypto library도 같이 교체하셨나요? libssl.so.1.0.0과 같은 directory에 들어있는 libcrypto.so.1.0.0을 말씀드리는 것입니다. 만약 이것을 같이 교체하지 않으셨다면 libssl과 libcrypto가 맞지 않아서 "version 어쩌구 저쩌구" 하는 error message를 주는 경우는 본 적이 있습니다.
제 생각에는 file을 copy하던 symbolic link를 하건 그것은 문제가 없을 겁니다. 제가 식견이 짧은 것인지는 모르나 UNIX 계열 OS에서 실제 file이 아니고 symbolic link라서 뭐가 안된다는 이야기는 못들어 보았습니다. 그러나, 제가 틀릴지 않는다고 장담은 못하죠.
libssl과 libcrypto를 같이 교체해 봤더니 둘 다 이런 에러인지 경고인지 메시지를 냅니다.
… no version information available …
파일 이름은 같은데 strings 같은 명령으로 보면, libssl 같은 경우 분명히 1.0.1h와 1.0.1f로 버전이 다르게 나옵니다.
libcrypto에서는 사람이 볼 수 있는 버전 정보를 찾지 못하겠던데요.
간단한 실험 결과와 제 의견만 말씀드릴께요. 제 의견은 항상 틀릴 수 있으니 참고만 하세요.
일단, 제 의견으로는 libssl과 libcrypto는 같이 compile된 것을 사용하는 것이 맞다고 생각됩니다. 또한, canonical에서 1.0.1f를 패치했는데 version이 1.0.1f로 그대로 나오는지 어떤지는 저는 전혀 모르겠습니다. 일단 heartbleed가 있다고 가정하고 말씀드립니다. 그런 전제하에서…
결론적으로 말씀하신 것이 맞네요. 저도 호기심에 ssl 1.0.1h source code를 download받아서 compile한 후, /usr/local/ssl에 설치하고 libssl과 libbcryto를 symbolic link했더니 같은 message가 뜹니다. 근데, 저는 desktop이라서 libssl을 쓰는 app를 찾지 못했습니다. 그래서 libcrypto 만을 사용하는 ssh client를 사용했더니 같은 message가 뜨더라고요. 그런데, 이는 warning인 듯합니다. 동작에는 아무런 문제가 없어 보입니다. 원리상으로도 문제가 없어야 할 것이라고 생각됩니다. API가 바뀐것도 아니고 bug fix version인데 달라야할 이유가 없지 않나요? pdh0710님의 경우에도 message는 뜨지만 동작엔 문제가 없지 않을까 짐작됩니다만…
그 경고 메세지마저 없애고 싶다면, 결국 app (제 경우엔 ssh, pdh0710님의 경우엔 php-fpm)을 다시 source에서 compile해야 한다는 결론에 이르게 된다는 것이 제 의견입니다. 그런데, 이것만 하면 된다면 모르겠는데, 사실은 libssl libcrypto를 사용하는 package가 제법 많을 겁니다. 이것들을 모두 일일히 source compile한다는게 말이 안되는 것 같아요. 그렇다면 결국 선택의 문제가 아닐까 싶습니다. message가 뜨는 귀찮음을 감수하고 안전을 택하던지, 메시지 뜨는 것이 싫으니 안전을 희생하던지…
아니면, libssl libcrypto libray는 현재 상태대로 그대로 두고, server program으로 자주 쓰시는 것 (php-fpm 처럼 안전에 중요한 것)만 1.0.1h libray에 link되도록 source compile하는 방법이 가장 현실적인 것이 아닌가 싶습니다.
잘 되시길 바랍니다.
우분투의 openssl은 update를 모두 받아서 설치했다면 이미 패치가 되었다고 합니다.
다음의 글을 참조하세요. 패치가 설치되었는지 확인하는 방법도 제시되어 있네요.
[url:1cxh2v6k]http://askubuntu.com/questions/450151/is-ubuntu-14-04-secure-against-heart-bleed-bug[/url:1cxh2v6k]
일단 우분투도 upgrade를 꾸준히 하면 버그 패치가 되는 것 맞군요. 이건 다행이네요.
저도 어제 이 문제 때문에 여러가지 해봤는데요. 확실히는 모르겠고 말씀처럼 직접 컴파일해서
사용하는 것과 관련 있다고 추측하고 있습니다.
제가 php-fpm과 openssl 최신 버전 101.h는 직접 컴파일했구요. 자동 설치되어 있고 php-fpm이 사용한다는
openssl 1.0.1f버전은 apt-get으로 우분투에서 공식으로 배포하는 버전입니다.
실험삼아 공식배포버전(구버전1.0.f) 라이브러리 파일을 컴파일버전(최신버전1.0.1h)으로 강제로 교체한 다음
php-fpm을 컴파일-설치해봤습니다. 이 과정이 php-fpm의 소스코드 가지고 configure->make->install 하는 단계로 이뤄지죠.
그런데 강제 교체한 최신버전 라이브러리를 쓰면 php-fpm configure 단계부터 openssl과 관련된 에러를 만들면서 멈춰버립니다.
아마도 openssl 공식배포 버전을 build할 때는 버전을 식별할 수 있는 어떤 signature를 기입하는데
제가 직접 컴파일한 openssl 라이브러리에는 그런 signature가 빠지니까 버전 인식이 안된다며
동작을 않거나 경고를 내는 것 아닐까 추측하고 있습니다.
공식배포 패키지 build할 때 signature를 기입하는 방법이 있는가요?