주간 IT

2019.12월 1주 – SSH/GPG 해킹 주의

PyPI 리포지터리에 악성 라이브러리 등록
python3-dateutil, jeIlyfish (dateutil, jellyfish 라이브러리를 변조)
SSH/GPG 키를 해킹해 http://68.183.212.246:32258로 전송
해당 라이브러리 사용했다면 1년간 쓴 SSH/GPG 변경할 것

2019년 12월 4일, 악성 파이썬 라이브러리 주의보

2019년 12월 첫째 주 소식을 전합니다.

파이썬 보안 팀은 악성 변조(트로이잔)를 당한 파이썬 라이브러리 2개를 PyPI( Python Package Index)에서 제거했다고 밝혔습니다. 이 파이썬 라이브러리들은 설치된 컴퓨터에 있는 개발 프로젝트에서 SSH와 GPG키를 빼돌려 특정 IP로 전송하는 것으로 알려졌습니다.

“python3-dateutil,” “jeIlyfish” 라는 이름을 가진 이 두 라이브러리는 이름에서 알 수 있듯이 “dateutil,” “jellyfish“라는 두 유명한 파이썬 라이브러리의 이름을 흉내내거나 비틀어 (typosquatting) 만든 라이브러리로서 둘 다 olgired2017라는 아이디를 가진 개발자(PyPI 및 GitLab 계정명)에 의해 제작/배포 되었습니다.

이 두 악성 클론 라이브러리들은 2019/12/1 일요일에 독일 개발자인 루카스 마티니( Lukas Martini )에 의해 발견되었고, 그 다음날인 12/2에 루카스가 dateutil 개발자들과 PyPI 보안팀에 이를 리포팅하면서 모두 PyPI 리포지터리에서 삭제되었습니다.

python3-dateutil은 2019년 11월 29일에 PyPI에 생성, 업로드된 반면, 놀랍게도 jeIlyfish는 2018년 12월 11일에 업로드되어 약 1년 간 사용자들에게 배포되어 왔었습니다.

SSH와 GPG키를 해킹

루카스에 따르면 이 악성코드는 jeIlyfish 라이브러리에만 존재하고, python3-dateutil 라이브러리는 이 jeIlyfish 라이브러리를 임포트(import)하는 방식으로 악성코드를 작동시킨다고 합니다.

이 악성코드는 해쉬 리스트를 GitLab 리포지터리에서 다운받아 읽는다고 알려졌고 이 해쉬들의 특징, 목적을 알기 위해서는 더 자세한 조사가 필요했습니다.

ZDNet은 dateutil 개발팀원인 폴 갠슬(Paul Ganssle)씨에게 이 악성 코드를 더 자세히 살펴볼 것을 부탁했고 아래와 같은 답변을 얻을 수 있었습니다.

“jeIlyfish 라이브러리 안에 있는 악성 코드는 hashsum이라는 별 의미 없어 보이는 파일을 깃랩 리포지터리에서 다운받습니다. 그리고 이 파일을 복호화하여 파이썬 파일로 바꾼다음 이를 실행합니다.” (실행가능한 파이썬 스크립트 파일인 **.py 형태로 바꾸는 것으로 추측됨 – 블로그 역자 주)

“이 파이썬 파일은 사용자 컴퓨터에서 SSH와 GPG 키 파일을 빼돌린 다음 이를 http://68.183.212.246:32258 주소로 전송하는 것으로 보입니다.”

“또 이 파일은 몇몇 디렉토리를 찾아서 저장해놓는 것으로 보입니다. 홈 디렉토리(/home 으로 보임 – 역자 주), 파이참(PyCharm) 프로젝트 디렉토리 같은 곳 말이죠.”

“이들 디렉토리 패쓰를 저장해놓는 이유는 제 추측에는 자격 증명(credentials)이 필요한 프로젝트는 어떤 프로젝트들인지 탐색하기 위해서로 보입니다. 그리고 나서 해커가 사용자의 프로젝트를 해킹하려고 하는거죠.”

파이썬 개발자 분들은 지금 당장 파이썬 프로젝트를 체크해보세요!

olgired2017라는 해커가 dateutil 클론을 만든 이유는, 오리지날 dateutil 라이브러리의 유명세를 빌려 감염률을 높이고 금전적 이윤을 얻기 위함으로 보입니다. 하지만 역으로 매우 유명한 라이브러리의 이름을 빌렸기 때문에 오히려 개발자들의 많은 주시를 받게 되어 해킹 활동이 모두 발각되어 버렸습니다.

두 라이브러리 내에 심어진 악성코드를 제외하면 두 라이브러리는 오리지날 라이브러리와 동일합니다.

파이썬 개발자분들은 다운로드 또는 임포트한 라이브러리를 꼭 체크하셔서 사용해왔던 패키지가 정확한 패키지 이름을 가지고 있는지 꼭 확인하셔야 합니다.

만약 변조된 패키지를 사용한 흔적을 찾으셨다면 지난 1년 간 사용해왔던 SSH 및 GPG 키를 모두 삭제하시길 권장합니다.

이러한 악성 패키지가 발각된 것은 처음이 아니며 PyPI팀이 패키지 이름을 변조한 악성 패키지를 적발해 공식 리포지터리에서 제거한 것은 이번이 6번째입니다.

유사 사례 링크: 2017년 10월 (10개 패키지), 2018년 5월 (1개 패키지), 2018년 10월 (12개 패키지), 2018년 12월 (18개 패키지), 2019년 6월 (3개 패키지).

기사 작성 및 번역 출처:
- https://www.zdnet.com/article/two-malicious-python-libraries-removed-from-pypi/

2019.11월 4주 – PyPy v7.2 릴리즈

64-bit aarch64 ARM architecture 지원
CFFI 모듈 관련 업데이트
PyPy 샌드박스 부활
더 빠른 성능과 더 적은 메모리를 요구하는 새로운 JSON 디코더

2019년 10월 14일, PyPy v7.2 릴리즈 소식

* PyPy 최신 버전(청록색) VS CPython 2.7.11
**X축: 성능 측정을 위한 벤치마크 작업,**
**Y축: 실행 시간(작을 수록 우수한 성능)**
이미지 출처

2019년 11월 4주차 소식부터 시작하는 주간 파이썬의 첫 번째 소식으로 어떤 주제를 고를지 고민했습니다. 그다지 특별한 뉴스가 없어보이는 11월 4주차였던지라 가장 근래의 소식에서 제일 중요하다고 판단된 뉴스를 꼽았습니다. 따라서 약간은 때 지난(?) 소식이지만 PyPy 7.2버전 릴리즈 내용을 소개할 까 합니다.

PyPy?

PyPy는 “JIT 컴파일을 지원하는 파이썬”으로서 기존의 인터프리터 방식(=소스 코드를 한꺼번에 모두 컴파일한 후 실행)과 달리 JIT 컴파일링(=소스 코드에서 실행할 부분만을 실행 시점에 골라서 컴파일한 후 실행)을 지원합니다. 마치 Java의 바이트코드 컴파일처럼 말입니다.

JIT 컴파일링은 같은 코드를 매번 해석(컴파일)할 필요가 없이 자주 쓰는 코드를 캐싱한 후 추후 호출 시 캐싱한 코드를 불러와 쓰기 때문에 속도 측면에서 유리합니다.

PyPy는 수행 작업에 따라 C로 구현한 CPython보다 더 빠르며, 파이썬 기본 인터프리터보다 최대 25배 이상 빠른 결과도 존재한다고 합니다(Python 2.7.11 x86_64, PyPy 5.1.0 x86_64 기준)(출처).

undefined

PyPy v7.2

PyPy 7.2는 Python2와 Python3에 각각 대응되는 PyPy2.7, PyPy3.6로 구성되어 있습니다.

PyPy 2.7에 대응되는 기존 파이썬 버전: Python 2.7
PyPy 3.6에 대응되는 기존 파이썬 버전: Python 3.6

PyPy 2.7은 CPython 2.7.13를, PyPy 3.6은 CPython 3.6.9를 지원하는 스탠다드 라이브러리를 포함하고 있습니다.

PyPy 7.2는 기존 PyPy버전과 100% 호환되며 여러 버그픽스를 포함하고 있기 때문에 기존 버전 사용자에게 이번 업데이트 설치를 강력히 권장합니다.

PyPy 7.2 다운로드 링크

이번 업데이트의 특징은 아래와 같습니다.

64-bit aarch64 ARM architecture 지원
CFFI 모듈 관련 업데이트
- PyPy 2.7이 CFFI 기반 _ssl 모듈을 다시 사용함
- CFFI 기반 _ssl 모듈이 cryptography 2.7을 사용하도록 업데이트 되었음
- _hashlib 모듈과 crypt(파이썬 3에서는 _crypt) 모듈이 CFFI 기반으로 변환됨
- CFFI 백엔드 1.13.0으로 업데이트
PyPy 샌드박스 부활
더 빠른 성능과 더 적은 메모리를 요구하는 새로운 JSON 디코더
- JIT에 최적화된 특수한 딕셔너리를 사용

64-bit aarch64 ARM architecture 지원

이제 PyPy는 64-bit ARM으로 알려진 AArch64 플랫폼을 지원합니다. 이번에 AArch64 플랫폼이 PyPy 지원 목록에 추가되면서 PyPy는 총 6개 아키텍처를 지원합니다:
x86 (32 & 64bit), ARM (32 & 64bit), PPC64, s390x.

다음 그래프는 x86_64 리눅스 랩탑, AArch64 플랫폼에서 PyPy(7.1.1)를 사용(hg id 2417f925ce94) 했을 때 CPython(2.7.16)과의 성능을 비교한 것입니다.

X축: 벤치마크 셋팅,
Y축: CPython 대비 속도 향상배수 (1x보다 높을수록 Cpython보다 뛰어남)

CFFI 모듈 관련 업데이트

이번 CFFI 모듈 업데이트는 크게 2가지 의미가 있습니다.

PyPy 사용자와 패키지 제작자들은 _hashlib, 와 crypt같은 라이브러리들을 업데이트 시 (cd lib_pypy; ../bin/pypy _*_build.py)를 실행하기만 하면 됩니다.
단일 런타임 네임스페이스를 가진 리눅스와 같은 플랫폼을 사용할 때, PyPy 자체는 더 적은 숫자의 시스템 공유 오브젝트(system shared objects: DLLs)를 필요로 하게 되었기 때문에, 서로 다른 CFFI/C확장 모듈이 서로 다른 버전의 시스템 공유 오브젝트(예: 버전만 다른 동일한 DLL 오브젝트)를 PyPy로 로드할 때 충돌이 발생하지 않게 됩니다(issue 2617).

PyPy 샌드박스 부활

2019년 8월부터 이미 예고되었던 바와 같이 PyPy를 마치 리눅스의 SECCOMP과 같이 OS 레벨에서 독립하여 사용할 수 있게 만든 PyPy 샌드박스가 곧 릴리즈된다고 합니다. PyPy 샌드박스는 사용자의 파이썬 프로그램 전체를 PyPy로 실행하도록 만든 독립된 환경입니다(샌드박스의 의미를 잘 생각해보면…). PyPy 샌드박스에 관한 자세한 내용은 이곳을 참조하세요.

새로운 JSON 디코더

PyPy 7.2의 가장 큰 특징으로 보이는 새로운 JSON 디코더입니다. PyPy 7.2에서는 map과 string caching을 사용해 JSON 디코딩 성능에 큰 향상을 가져왔다고 합니다.

아래 그림들은 PyPyFULL(=PyPy 7.2에 도입된 새로운 디코더)에 비교했을 때 기존 PyPy 5.8~7.1 버전에서 사용된 JSON 디코더의 디코딩 속도 및 메모리 점유율을 나타낸 그래프입니다.

PyPyBaseline은 JSON Parser가 도입된 최초 버전인 PyPy 5.8 버전의 JSON 디코더를, PyPyKeyStringCaching과 PyPyMapNoCache은 PyPy 5.9~7.1 버전까지의 JSON 디코더를, PyPyFull은 PyPy 7.2에서 새롭게 사용된 디코더를 가리킵니다.

X축: 벤치마크용 JSON 데이터셋
Y축: PyPyFULL(=PyPy 7.2의 새로운 디코더)에 비교했을 때 기존 디코더의 디코딩 시간비율
(1.0은 기존 디코더와 새 디코더의 수행 시간이 같음을 의미함. 낮을 수록 우수한 성능)

X축: 벤치마크용 JSON 데이터셋
Y축: PyPyFULL(=PyPy 7.2의 새로운 디코더)에 비교했을 때 기존 디코더의 메모리 점유 비율
(1.0은 기존 디코더와 새 디코더의 메모리 점유수준이 같음을 의미함. 낮을 수록 더 적은 메모리 점유)

아래 그림들은 PyPyFull 디코더 성능/메모리 점유율과 다른 JSON 디코더 성능/ 메모리 점유율을 비교한 그림입니다.

X축: 벤치마크용 JSON 데이터셋
Y축: PyPyFULL(=PyPy 7.2의 새로운 디코더)와 다른 디코더의 디코딩 수행 시간을 비교해 나타낸 비율
(1.0은 다른 디코더와 PyPy 7.2 디코더의 수행 시간이 같음을 의미함. 낮을 수록 우수한 성능)

X축: 벤치마크용 JSON 데이터셋
Y축: PyPyFULL(=PyPy 7.2의 새로운 디코더)와 다른 디코더의 메모리 점유수준을 비교해 나타낸 비율
(1.0은 다른 디코더와 PyPy 7.2 디코더의 메모리 점유 수준이 같음을 의미함. 낮을 수록 우수한 성능)

위의 디코딩 시간/메모리 점유 수준 그래프로만 보자면 PyPy 7.2의 JSON 디코더는 CPython의 JSON 디코더에 비해 월등한 성능을 자랑하고 있는데요, 자세한 정보는 다음을 통해 확인하시기 바랍니다.

기사 작성 및 번역 출처:

https://morepypy.blogspot.com/
http://doc.pypy.org/en/latest/sandbox.html
https://speed.pypy.org/
https://namu.wiki/w/JIT
https://cffi.readthedocs.io/en/latest/

주간 IT를 개간하며…

C로 보인다면 기분탓입니다.

주간 IT는 매주 새롭고 재미있는 IT/프로그래밍 소식을 한국말로 쉽고 명확하게 풀어 전달하는 주간 온라인 매거진입니다.

주간 IT는 프로그래밍과 데이터 과학에 관심이 많은 전문 기술 번역가 출신 주인장이 운영합니다.

주간 IT에서 매주 소개하는 내용은 모두 주인장이 직접 선택, 번역, 편집한 해외 IT/프로그래밍 뉴스를 소개하는 매거진이며 원본 링크를 본문에 첨부합니다.

주간 IT를 시작하는 이유?

번역은 개발자에게 귀찮은, 또 어려운 일입니다.
최신 IT/프로그래밍/데이터 과학 소식을 우리말로 빠르고 친절하게 매주 전달하는 곳이 없습니다.
(주간 매거진 형태의 개인 블로그 포스트가 드뭅니다)
개발 경력과 전문 번역 경력을 모두 가진 사람은 많지 않습니다.

프로그래밍을 경력은 Python 약 3년 (Built-ins, Numpy, Pandas, Tensorflow, Scikit-Learn, etc.) 이며 석사 과정과 모 검색 엔진 회사에서 일하면서 데이터 분석과 기계 학습 분야에 사용했고 주 관심 분야는 강화학습 (Deep Reinforcement Learning)이었습니다(OpenAI/Gym, Baselines).

번역 경력은 약 2년이며 IT 회사의 테크니컬 라이터로 활동하기도 했습니다.

매주 전 세계 여러 커뮤니티에 올라오는 최신 토픽과 뉴스 중 실무에 가장 유용하다고 판단되는 것들만 엄선하여 전달합니다.

따라서 이 블로그는 프로그래밍과 데이터 과학을 처음 접하시거나 공부하시는 학생, 개발자에게는 다소 불친절할 수 있습니다.

주간 IT는 최신의, 유용한 IT/프로그래밍 소식을 빠르게 편집, 번역하여 업무에 바빠 영어로 된 새 소식을 자세히 읽을 시간이 없는 현업 종사자, 연구원에게 전달하기 위해 개간되었습니다.

따라서 과감한 편집과 초월 번역도 불사하며 정확한 콘텍스트를 읽기 쉽게 전달하는 데에 집중합니다.

한국에서 쓴 IT 기술 서적을 오역과 직역 떡칠로 쳐다보기도 싫었던 (호되게 데였던) 개발자분들에게 조금이나마 눈 시원한 공간이 되고자 합니다.