sudo – Heap buffer overflow 취약점 Baron Samedit [CVE-2021-3156]

sudo 명령의 -s 옵션 또는 -i 옵션을 이용하여 이스케이프(‘\’) 으로 Heap buffer overflow 취약점이 발견 되었음 ‘ㅅ’a

root 권한 탈취가 가능하므로 심각한(important) 취약점 이라고 볼수 있다.

 

취약점 테스트

위와 같이 Segmentation fault 가 발생한다면 취약한 버전 으로 업데이트가 필요로 하다 ‘ㅅ’a

 

업데이트 CentOS 7 ~ 8

 

업데이트 Ubuntu 14.04 ~ 21.04

 

시스템 재 부팅은 불필요 하다 ///ㅅ///

 

https://access.redhat.com/ko/security/vulnerabilities/5740281

https://ubuntu.com/security/CVE-2021-3156

 

AWS SES – SMTP 계정 의 키 변경

AWS SES (Simple Email Service) 는 직접 구축이 어려운 이메일 서비스를 제공한다.

sendmail 으로 SMTP 구성을 사용할 수 있지만 보통 스팸 방지를 위한 여러 솔루션에 의해서 차단이 되기 때문에

직접 sendmail 서비스를 구성하고 서비스 하기 위해서는 광범위한 공부가 필요 하다.

1. sendmail – smtp 구축

2. KISARBL 등록 (이것은 한국의 포털 쪽으로 메일 서비스 원활히 발송하기 위해 필요 하다.)

3. ReverseDNS 등록 (이건 해외 포털 서비스 쪽과 관련이 있다. Internet Service Provider 에서 등록이 가능하다. – KT, SK, U+ 등등..)

4. DKIM, DMARC 설정 (해외 포탈 gmail, yahoo 등등)

아울어서 주기적인 IP 신뢰도 관리를 위해 서버내에서 발송되는 메일을 추적, 통제 해야 한다.

 

AWS SES 는 월 62,000건 까지는 무료로 발송이 되며 이후 초과 되는 1000개의 메일당 약 100~150원 정도의 비용이 발생 한다.

물론 수신자의 스팸 신고가 많거나(1%) 허위 메일 주소로 발송(5%)되면 메일 발송 서비스가 차단 된다.

 

메일 발송을 위한 SMTP 계정은 생성을 하게 되면 auth 계정이 할당 되게 되며 사전에 등록된 메일 주소로만 발송을 할 수 있다.

문제는 ID / PW 형식 이기 때문에 유출 되었거나.. 혹은 패스워드 생성일이 오래 되면 보안상 바꾸어 주어야 한다.

 

AWS – IAM 에서 일반적으로 생성하는 액세스 키는 20글자 시크릿 키는 40 글자 를 차지 한다.

2021-01-22_151318

 

AWS – SES 에서는 SMTP 계정을 만들때 패스워드 길이가 44 글자를 가진다.

즉 SES 메뉴에서 “Create My SMTP Credentials” 생성한 계정을 사용할 수 있다.

2021-01-22_151735

 

그래서 찾아 보니 아래와 같은 메뉴얼을 찾을 수 있었다.

https://aws.amazon.com/ko/premiumsupport/knowledge-center/ses-rotate-smtp-access-keys/

 

근데 이해는 잘 되지 않는…

종합해보면 기본으로 제공 되는 파이선코드 를 이용하여 컨버팅 해서 써야 한다는 말이다.

 

시스템 엔지니어링을 하는 입장에서는 생성된 값을 테스트 하고 넘겨 줘야 하는 부분도 있고 python3 전용인 부분도 조금 마음에 안들어서

패스워드 생성 후 SMTP 테스트를 진행 하도록 하였다. ‘ㅅ’a

 

사용 방법은 다음과 같다.

 

IAM 아무렇게나 생성된 계정에서는 작동하지 않고, 계정에 ses:SendRawEmail 권한이 부여 되어 있어야 작동 한다. (SES 에서 생성한 계정은 이미 부여가 되어 있을 것임.)

 

ps. 위에 예시된 엑세스키/시크릿키/SMTP비밀번호는 이 글을 포스팅 한 이후 모두 삭제 했으니까 굳이 테스트 해보지 않으셔도 된다. ‘ㅅ’a

유니코드 문서의 Byte Order Mark

보통 일반적으로 접하게 되는 문서는 ASCII 혹은 UTF8 문서 이다.

다만 문서중 UTF8 의 경우 일반 UTF8, UTF8 (BOM) 문서가 있다.

 

UTF8 (BOM)의 경우 윈도우 메모장에서 UTF8문서를 생성할 경우 파일의 첫부분에 삽입되게 되며 “EF BB BF” 값을 가진다.

또란 실제 삽입되어 있지만 메모장으로 파일을 불러들였을때에는 보이지 않도록 처리가 되어 있다.

 

즉 있는지 없는지 확인이 안되고 오류를 발생시키기 때문에 문제가 된다.

 

아래 처럼 utf8 에서는 ea b0 80 = “가” 을 나타낸다.

 

일반 ASCII 파일 혹은 일반(리눅스에서 생성한) UTF8 문서를 확인해보면 아래와 같다. # = 23 | 가 = ea b0 80 | \n(엔터) = 0a

 

윈도우 메모장으로 생성\하여 BOM 이 삽입된 파일은 다음과 같다.  utf8(bom) = ef bb bf | \r\n(윈도우엔터) = 0d 0a

 

위와 같은 이유로 윈도우에 mysql 을 설치 하고 메모장으로 my.ini 파일을 수정한뒤에 저장 하면 UTF-8(BOM) 으로 저장 되어 mysql 서비스 시작이 되지 않는다.

메모장으로 하더라도 “다른 이름으로 저장” 시 인코딩을 ANSI 으로 설정하고 저장 기존 파일명과 같게 저장 하는 방법이 있다. (근데 사람은 같은 실수를 반복하기 때문에…)

2021-01-14_113358

윈도우 내에서의 문서 작업은 메모장이 아닌 BOM 없이 생성 가능한 에디터를 사용하는 습관을 들여야 할것 같다 ‘ㅅ’a

무료 툴 : AcroEDIT

 

PS. UTF16 의 경우 UTF16BE , UTF16LE 두가지 형식이 존재하며 두가지 모두 Byte Order Mark 를 가지고 있다. 아래표 참조 ‘ㅅ’a

 Byte
Order
Mark
문자 길이HEX 코드
( # )
HEX 코드
( 가 )
HEX 코드
( 핣 )
UTF16BEFE FF4 Byte23 00AC 00D8 A9
UTF16LEFF FE4 Byte00 23AC 00D8 A9
UTF8(BOM)EF BB BF1 ~ 3 Byte23EA B0 80ED 95 A3
UTF8-1 ~ 3 Byte23EA B0 80ED 95 A3
ASCII1 Byte23표현 불가
UTF32BEFE FF 00 008 Byte23 00 00 00AC 00 00 00D8 A9 00 00
UTF32LE00 00 FF FE8 Byte00 00 00 2300 00 AC 0000 00 D8 A9

Let’s encrypt 사용 방법 변경

신규 서버를 세팅 하고 SSL 추가 했을때 당황스럽게도 위와 같은 메세지를 뿌리며 certbot-auto 가 작동하지 않았다.

 

certbot-auto 의 경우 실행 시킬때마다 자동 업데이트를 하는데 버전이 1.11 버전으로 되어 있을경우 발생하는 메세지로 확인이 된다.

 

링크를 따라 갈 경우 snap을 이용해서 설치해서 사용하라고 안내 되어 있다.

snap 은 yum 혹은 apt-get 과 같은 패키지 관리 툴 이다.

 

CentOS 7/8 의 경우 epel-release 가 설치 되어 있다면 yum 으로 snap을 설치할 수 있다.

 

이후에 snap 을 이용하여 certbot 을 설치한다.

주의: 기존에 yum 이나 apt-get 혹은 dnf 으로 설치된 certbot은 삭제 하고 진행 해야 한다.

 

/usr/bin 안으로 링크를 생성하기 때문에 ssl 발급을 위해서는 아래 명령어를 사용하면 되겠다.

 

certbot 을 업데이트한 사유로는 스크립트가 python 2 기반으로 작동을 하는데 사용하는 사람들이 늘어나니 특이사항이 많아 한계를 느낀것으로 보인다. (OS의 python 2 제거, 각사용자의 venv 등등) 그래서 snapd 를 이용하여 python 2.6 버전을 이용하는것으로 확인 된다.

장점이 하나 있는데 snapd 에서 자동으로 renew 를 해준다고 한다 ‘ㅅ’a 즉 renew 명령어를 계속 반복하지 않아도 된다.

 

ps . 기존에 git 에서 clone 을 해서 사용한 경우 삭제까지는 필요 없는듯 하고, renew의 경우 메세지는 나오지만 갱신하는데에는 문제가 없없다.

 

ps2. CentOS 6은 https://centos.pkgs.org/6/epel-i386/snap-0.6-1.el6.noarch.rpm.html 이게 도움이 될 수 있는데 실제 서버가 없어서 테스트 하지 못했음…

 

ps3. snap 설치가 되지 않는 리눅스의 경우 certbot-auto 구버전 (1.9.0.dev0) 의 실행파일만 덧씌운뒤 renew 실행하면 당장 급한불을 끌 수 있음.

python – apache pyarrow 를 이용한 parquet 생성 및 테스트

apache 재단에서 진행 되는 프로젝트 이다. python, java, R 등등 많은 언어를 지원 한다.

CSV (Comma-Separated Values)의 가로열 방식의 데이터 기록이 아닌 세로열 기록 방식으로 기존 가로열 방식에서 불가능한 영역을 처리가 가능하도록 한다.

2020-12-24_135314

이미지 출처: 훈민정음 나무위키

 

차이점을 그림으로 표현하자면 아래와 같다.

2020-12-28_090730

문서를 모두 읽는다 에서는 큰 차이가 발생하지 않지만 구조적으로 모든 행이 색인(index) 처리가 된 것처럼 파일을 읽을 수 있다.

sql 문으로 가정으로 “(SELECT * FROM 테이블 WHERE 재질 = ‘철’)” 을 찾게 될 경우 index 가 둘다 없다는 가정하에서

CSV 는 9개의 칸을 읽어야 하지만 (재질->무게->산화->나무->가벼워->탄다->철->무거워->안탄다->return)

parquet 의 경우 5개의 칸만 읽으면 된다. (재질->나무->철->무거워->안탄다->return)

압축을 하더라도 컬럼별 압축이 되기 때문에 필요한 내용만 읽어서 압축해제 하여 데이터를 리턴 한다.

 

적당한 TSV (Tab-Separated Values)데이터를 준비 한다.

2020-12-24_145706

 

python 을 이용하여 TSV 파일을 읽고 python 의 pyarrow를 이용하여 parquet 파일을 생성 하고 읽는 테스트를 한다. (pyarrow, pandas 는 pip install pyarrow pandas 으로 설치할 수 있다.)

 

TSV -> parquet 압축률(높을수록 좋음) 및 처리 시간(낮을수록 좋음)

 defextMBcompress ratioprocessing time
python 2.7
processing time
python 3.6
txt.txt58.8 MB
gzip.txt.gz16.3 MB72%3.24 sec
pyarrowwrite_table,
compression='none'
.parquet
40.1 MB32%0.74 sec0.93 sec
write_table,
compression='snappy'
24.8 MB58%1.31 sec 0.95 sec
write_table,
compression='lz4'
24.7 MB58%0.79 sec0.94 sec
write_table,
compression='zstd'
19.3 MB67%1.00 sec0.98 sec
write_table,
compression='gzip'
18.8 MB68%5.07 sec1.18 sec

읽기/쓰기 테스트 모두 AWS – EC2(m5.large-centos7) – gp2(100GB) 에서 진행 하였다.

 

parquet 을 생성한 이유는 파일을 읽을때 모든 컬럼인 index가 걸려있는것과 같이 빠르게 읽기 위함이니 읽기 테스트도 해본다.

 

TSV, parquet 파일 읽기 테스트 (pandas, pyarrow)

 defextMBprocessing time
python 2.7
processing time
python 3.6
pandasread_csv.txt58.8 MB1.39 sec1.56 sec
read_csv,
compression='gzip'
.txt.gz16.3 MB1.68 sec2.06 sec
read_parquet.parquet
(none)
40.1 MB0.72 sec0.93 sec
.parquet
(snappy)
24.8 MB1.03 sec0.95 sec
.parquet
(lz4)
24.7 MB0.73 sec0.94 sec
.parquet
(zstd)
19.3 MB0.76 sec0.95 sec
.parquet
(gzip)
18.8 MB0.96 sec1.18 sec
pyarrowread_csv,
to_pandas
.txt58.8 MB1.01 sec1.30 sec
.txt.gz16.3 MB1.41 sec1.37 sec
read_table,
to_pandas
.parquet
(none)
40.1 MB0.69 sec0.90 sec
.parquet
(snappy)
24.8 MB0.99 sec0.89 sec
.parquet
(lz4)
24.7 MB0.69 sec0.92 sec
.parquet
(zstd)
19.3 MB0.75 sec0.95 sec
.parquet
(gzip)
18.8 MB0.95 sec1.22sec

 

이 문서 처음에 언급 했다 시피 대용량 파일을 처리 하기 위함. 즉 “빅데이터”(HIVE, Presto, Spark, AWS-athena)환경을  위한 포멧이다.

모두 테스트 해보면 좋겠지만 아직 실력이 부족해서 AWS athena 만 테스트를 진행 한다.

구조적으로 S3 버킷에 parquet 파일을 넣어 두고 athena 에서 테이블을(S3 디렉토리 연결) 생성 하여 SQL 문으로 검색을 하는데 사용 한다.

 

TSV, parquet 파일 읽기 테스트 (AWS – athena)

 ROW FORMAT SERDEextSearched
MB
processing time
(select target 2)
processing time
(select target 50)
athenaorg.apache.hadoop.hive.
serde2.lazy.
LazySimpleSerDe
.txt58.8 MB1.17 ~ 3.35 sec1.86 ~ 2.68 sec
.txt.gz16.3 MB1.37 ~ 1.49 sec1.44 ~ 2.69 sec
org.apache.hadoop.hive.
ql.io.parquet.serde.
ParquetHiveSerDe
.txt.parquet10.48 MB1.11 ~ 1.49 sec1.00 ~ 1.38 sec
.snappy.parquet4.71 MB0.90 ~ 2.36 sec0.90 ~ 1.00 sec
지원 불가.lz4.parquet지원 불가
.zstd.parquet
org.apache.hadoop.hive.
ql.io.parquet.serde.
ParquetHiveSerDe
.gzip.parquet2.76 MB0.89 ~ 1.17 sec0.90 ~ 1.85 sec

읽는 속도가 향상되었고 스캔 크기가 적게 나온다. (parquet 의 강점을 보여주는 테스트-스캔비용의 절감이 가능.)

 

athena 테이블 생성에 사용된 DDL 쿼리문 (TSV, parquet)

 

PS. 이건 저도 어려 웠어요…..