1

주제: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

쓸데없는 기우겠지만 혹시나 해서 질문드립니다.
플러그인 자체만으로 보안상의 문제를 일으킬 수 있을 가능성은 없는지 궁금합니다.

그리고 이번에 플러그인 자료실에 올라온 웹프린트 프로그램을 봤는데 (이분이 만든 것에 문제가 있다는 것은 아닙니다.)
(플러그인이라 봐야할지 어플리케이션이라 봐야할지 모르겠지만)
이런 방식으로도 누군가가 악의적으로 만든다면 모르는 사람이 받아서 사용한다고 할 때
충분히 관리자 정보를 가로챌 수 있도록 만들어낼 수도 있지 않을까요.

(알아내봤자 그다지 쓸모도 없고, 일부러 알아내려 그런 것을 만들려는 사람도 없을듯 하지만 말이지요.)

규니 (2006-05-02 21:24:38)에 의해 마지막으로 수정

세상 수 많은 사람들이 삶에 대해서 생각하고 말을 했다.
그 많은 사람들의 삶은 어떤 것인지 잘 모르겠지만 내가 생각하는 삶이란..
과거를 느끼고, 미래를 꿈꾸며, 현재를 살아가는 것!
하지만 지금의 나는...

2

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

기우..는 아닙니다.
충분히 그럴 가능성이 있고 또 마음만 먹으면 가능합니다.
관리자 정보는 큰 의미가 없을지 모르겠지만 다른 방법으로 악용할 소지는 충분히 있죠.

이전에도 그와 관련해서 몇번 말이 있었는데 아쉽게도 뚜렷한 해결책은 아직 없는거 같네요. sad

3

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

네 이부분은 현재 별도의 검증절차없이 공개하도록 하고 있기 때문에 문제가 있지요..
추후 커뮤니티가 조금더 커진다면, 플러그인을 검증하는 분도 생기지 않을까요..
현재 태터앤프렌즈가 맡기에는 조금 큰 일 같습니다. ㅠ.ㅠ

4

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

지금으로선 크게 문제될만한 것은 아닌듯 한데 괜히 부담만 드린듯해서 죄송스럽네요.

세상 수 많은 사람들이 삶에 대해서 생각하고 말을 했다.
그 많은 사람들의 삶은 어떤 것인지 잘 모르겠지만 내가 생각하는 삶이란..
과거를 느끼고, 미래를 꿈꾸며, 현재를 살아가는 것!
하지만 지금의 나는...

5

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

저도 가장 불안히 생각하는 것중 한가지 입니다.
어떤 플러그인을 다운 받아서 설치했는데 DB에 테이블을 생성하는걸 보고 겁이나더군요.
이거 악용만하면 데이터도 마음대로 수정하거나 파괴할 수 있겠구나 하고요.

6

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

JWC 작성:

저도 가장 불안히 생각하는 것중 한가지 입니다.
어떤 플러그인을 다운 받아서 설치했는데 DB에 테이블을 생성하는걸 보고 겁이나더군요.
이거 악용만하면 데이터도 마음대로 수정하거나 파괴할 수 있겠구나 하고요.

네 플러그인만 리뷰해줄 수 있는 프렌드분이 한분 계시면 좋을 듯 합니다.
도대체 어떤영향을 주는지, 이런것들이 궁금할때가 많거든요..
일단은 태터를 쓰시는 분은 모두 착한분이라는 믿음을 가지고 있습니다. ( 아직까지는... )
그런데, 성장을 거듭할 수록 나쁜사람들도 많이 생길것 같단 예상...조심스레 해봅니다.

7

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

chester 작성:
JWC 작성:

저도 가장 불안히 생각하는 것중 한가지 입니다.
어떤 플러그인을 다운 받아서 설치했는데 DB에 테이블을 생성하는걸 보고 겁이나더군요.
이거 악용만하면 데이터도 마음대로 수정하거나 파괴할 수 있겠구나 하고요.

네 플러그인만 리뷰해줄 수 있는 프렌드분이 한분 계시면 좋을 듯 합니다.
도대체 어떤영향을 주는지, 이런것들이 궁금할때가 많거든요..
일단은 태터를 쓰시는 분은 모두 착한분이라는 믿음을 가지고 있습니다. ( 아직까지는... )
그런데, 성장을 거듭할 수록 나쁜사람들도 많이 생길것 같단 예상...조심스레 해봅니다.

"아직"없을때 미리 대비를 해둬야 그런 일을 하려고 마음먹는 사람이 생기지를 않습니다.
한번 일이 터지면 소 잃고 외양간 고치는 정도가 아니라 소도둑이 때로 몰려와서 외양간을 때려부수고 소를 훔쳐가기 마련이거든요.
아무리 늦어도 1.1이 release 될때까지는 대비책을 세워둬야한다고 생각합니다.

8

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

Peris 작성:
chester 작성:
JWC 작성:

저도 가장 불안히 생각하는 것중 한가지 입니다.
어떤 플러그인을 다운 받아서 설치했는데 DB에 테이블을 생성하는걸 보고 겁이나더군요.
이거 악용만하면 데이터도 마음대로 수정하거나 파괴할 수 있겠구나 하고요.

네 플러그인만 리뷰해줄 수 있는 프렌드분이 한분 계시면 좋을 듯 합니다.
도대체 어떤영향을 주는지, 이런것들이 궁금할때가 많거든요..
일단은 태터를 쓰시는 분은 모두 착한분이라는 믿음을 가지고 있습니다. ( 아직까지는... )
그런데, 성장을 거듭할 수록 나쁜사람들도 많이 생길것 같단 예상...조심스레 해봅니다.

"아직"없을때 미리 대비를 해둬야 그런 일을 하려고 마음먹는 사람이 생기지를 않습니다.
한번 일이 터지면 소 잃고 외양간 고치는 정도가 아니라 소도둑이 때로 몰려와서 외양간을 때려부수고 소를 훔쳐가기 마련이거든요.
아무리 늦어도 1.1이 release 될때까지는 대비책을 세워둬야한다고 생각합니다.

문제는 항상 '자원'의 문제로 귀결되지요... Peris 님 한번 나서주시겠습니까 ?? 
( 조심스럽게...~~ ^^ )

9

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

chester 작성:

문제는 항상 '자원'의 문제로 귀결되지요... Peris 님 한번 나서주시겠습니까 ?? 
( 조심스럽게...~~ ^^ )

리뷰를 해달라는 말씀이신가요?
전에도 썼었지만 저는 플러그인 자체에서 근본적인 해결책이 있어야된다고 생각합니다.
물론 그 이전까지는 다른 방법들을 활용해야겠지만요. smile

아 잠깐 말이 샜는데; 리뷰를 말씀하시는거라면 구체적으로 어떤걸 말씀하시는건지를 알아야 될거 같네요.
물론 참여할 의향은 있습니다.(혼자서 다 하는건 무리일거 같기는 하지만요.; )

10

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

플러그인의 보안등급을 직접 측정하는 부분을 플러그인 모듈 안에 추가해야 되지 않을까 싶습니다.

복잡하게 생각하면 복잡한데, 간단하게 생각하면 플러그인 내용 중에 SQL 쿼리가 존재하는지, 자바스크립트가 존재하는지 등등만 검사해서 표시하도록 해도 해결은 되지 않을까 싶습니다. 어떨까요?

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

11

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

inureyes 작성:

플러그인의 보안등급을 직접 측정하는 부분을 플러그인 모듈 안에 추가해야 되지 않을까 싶습니다.

복잡하게 생각하면 복잡한데, 간단하게 생각하면 플러그인 내용 중에 SQL 쿼리가 존재하는지, 자바스크립트가 존재하는지 등등만 검사해서 표시하도록 해도 해결은 되지 않을까 싶습니다. 어떨까요?

플러그인이 "미사용" 에서 "사용"으로 전환될때 내부적으로 validate 하고, 그 결과에 대해서 사용자에게 경고를 해주는것도 좋을거같습니다.
예를 들자면..

사용하시려는 ***플러그인은 다음과 같은 이유로 위험할 수가 있습니다.
* 이 플러그인은 DB에 테이블을 생성합니다.
* 이 플러그인은 DB에 레코드를 수정합니다.

이를 무시하고 플러그인을 사용하시겠습니까?

처럼 말이지요.

12

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

Kotoko 작성:

플러그인이 "미사용" 에서 "사용"으로 전환될때 내부적으로 validate 하고, 그 결과에 대해서 사용자에게 경고를 해주는것도 좋을거같습니다.
예를 들자면..

...

처럼 말이지요.

그렇게 하는 것이 좋겠군요. smile
플러그인 내용 중에서 경고되어야 할 명령들이 어떤 것들이 있을까요? 우선 생각나는 것들이,
create, alter, drop 정도와, javascript 정도의 문자열이 걸러져야 할 것 같은데, 다른 것들이 있을까요?

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

13

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

Kotoko 작성:
inureyes 작성:

플러그인의 보안등급을 직접 측정하는 부분을 플러그인 모듈 안에 추가해야 되지 않을까 싶습니다.

복잡하게 생각하면 복잡한데, 간단하게 생각하면 플러그인 내용 중에 SQL 쿼리가 존재하는지, 자바스크립트가 존재하는지 등등만 검사해서 표시하도록 해도 해결은 되지 않을까 싶습니다. 어떨까요?

플러그인이 "미사용" 에서 "사용"으로 전환될때 내부적으로 validate 하고, 그 결과에 대해서 사용자에게 경고를 해주는것도 좋을거같습니다.
예를 들자면..

사용하시려는 ***플러그인은 다음과 같은 이유로 위험할 수가 있습니다.
* 이 플러그인은 DB에 테이블을 생성합니다.
* 이 플러그인은 DB에 레코드를 수정합니다.

이를 무시하고 플러그인을 사용하시겠습니까?

처럼 말이지요.

플러그인 manifest에 보안등급(?)을 구분할 수 있는 safety element가 있습니다.
PHP 언어 특성상 compile(parse)-time에 사용되는 함수나 명령을 판단하는 것은 불가능합니다.
...

14

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

PAPACHA 작성:

플러그인 manifest에 보안등급(?)을 구분할 수 있는 safety element가 있습니다.
PHP 언어 특성상 compile(parse)-time에 사용되는 함수나 명령을 판단하는 것은 불가능합니다.
...

compile time이 아니라 플러그인 사용여부를 체크할 때 index.php를 텍스트로 읽어와 해석하는 것은 가능하지 않나요?

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

15

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

inureyes 작성:
PAPACHA 작성:

플러그인 manifest에 보안등급(?)을 구분할 수 있는 safety element가 있습니다.
PHP 언어 특성상 compile(parse)-time에 사용되는 함수나 명령을 판단하는 것은 불가능합니다.
...

compile time이 아니라 플러그인 사용여부를 체크할 때 index.php를 텍스트로 읽어와 해석하는 것은 가능하지 않나요?

index.php를 텍스트로 읽어 해석하는 것이 compile(parse)-time인데요,
악의적인 경우를 차단하는게 목적이기에 악의적으로 우회하지 못해야 하는데,
eval(), create_function(), call_user_func(), call_user_func_array() 이 사용되면 그렇게 하는게 불가능합니다. 이들을 사용하지 못하게 할 수 있겠지만...
또한 include 계열을 사용하면 역시 더 불가능해 집니다...

16

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

그렇군요 smile 이해했습니다. 인터프리터에서 해석하는 시간이 compile time이 아니라 문자열로 읽어들이는 것이 compile time이군요. php코드로써가 아니라 완전히 plain text로 읽어와도 compile time이 되는건가요?

C addictive people에게는 힘든 개념입니다. ㅠ_ㅠ

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

17

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

inureyes 작성:

그렇군요 smile 이해했습니다. 인터프리터에서 해석하는 시간이 compile time이 아니라 문자열로 읽어들이는 것이 compile time이군요. php코드로써가 아니라 완전히 plain text로 읽어와도 compile time이 되는건가요?

C addictive people에게는 힘든 개념입니다. ㅠ_ㅠ

단순한 문자열이 아니라 PHP 코드로서 읽어들여 syntatic analysis를 하기 때문에 compile(parse)-time입니다.
syntactic analysis를 해서 AST를 얻어 interpret하면 run-time이 되겠지요.

참고로, 태터툴즈 배포판에 사용되는 optimizer는 syntactic analysis를 통해 compile(parse)-time에 optimizing합니다. 그래서 require와 require_once가 있을 때, 전자는 compile-time에 결정되어 optimizing할 수 있지만 후자는 그렇지 못합니다. 또한 최근에 inureyes님이 글편집 팝업창과 관련하여 commit한 코드 중에 다음은 compile-time에 optimzing할 것이 별로 없습니다.

require ROOT . (isset($_GET['popupEditor']) ? '/lib/piece/owner/contentMenu81.php' : '/lib/piece/owner/contentMenu70.php');

그래서 다음과 같이 수정한 것이지요.

if (isset($_GET['popupEditor']))
    require ROOT . '/lib/piece/owner/contentMenu81.php';
else
    require ROOT . '/lib/piece/owner/contentMenu70.php';

18

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

inureyes 작성:

그렇군요 smile 이해했습니다. 인터프리터에서 해석하는 시간이 compile time이 아니라 문자열로 읽어들이는 것이 compile time이군요. php코드로써가 아니라 완전히 plain text로 읽어와도 compile time이 되는건가요?

C addictive people에게는 힘든 개념입니다. ㅠ_ㅠ

Compile 과정이라고 하기엔 거시기 하지만 그래도 그나마 적절한 용어가 Compile Time이라 할 수 있겠군요.

19

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

PAPACHA 작성:

단순한 문자열이 아니라 PHP 코드로서 읽어들여 syntatic analysis를 하기 때문에 compile(parse)-time입니다.
syntactic analysis를 해서 AST를 얻어 interpret하면 run-time이 되겠지요.

이제야 어디서 말이 엇갈렸는지 알 것 같습니다. smile

제 의견은 플러그인 사용을 체크하면 플러그인 php의 경로를 코드 검사 함수로 넘기고, 코드 검사 함수에서는 index.php를 완전히 텍스트로서 읽은 후 그 안에 문제가 될 명령어들이 포함되었는지 판단한 후 그 결과를 에러코드의 형식으로 돌려주는 것이었습니다. 에러코드에 따라 적절한 메세지와 선택창을 띄우고, 사용자의 선택에 따라 플러그인 사용/ 비사용을 선택하는 방식이지요.

PAPACHA 작성:

참고로, 태터툴즈 배포판에 사용되는 optimizer는 syntactic analysis를 통해 compile(parse)-time에 optimizing합니다. 그래서 require와 require_once가 있을 때, 전자는 compile-time에 결정되어 optimizing할 수 있지만 후자는 그렇지 못합니다. 또한 최근에 inureyes님이 글편집 팝업창과 관련하여 commit한 코드 중에 다음은 compile-time에 optimzing할 것이 별로 없습니다.

require ROOT . (isset($_GET['popupEditor']) ? '/lib/piece/owner/contentMenu81.php' : '/lib/piece/owner/contentMenu70.php');

그래서 다음과 같이 수정한 것이지요.

if (isset($_GET['popupEditor']))
    require ROOT . '/lib/piece/owner/contentMenu81.php';
else
    require ROOT . '/lib/piece/owner/contentMenu70.php';

optimizer가 그런 식으로 동작하고 있었군요.
앞으로의 코딩 스타일 정립에 굉장히 참고가 될 것 같습니다. big_smile

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

20

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

오호.. 요즘 Programming Language 시간에 하는 내용들이 나오는군요;; 저번 중간고사 범위가 lexical/syntatic analysis였다는...-_-;;

확실히, php 코드를 분석해서 그것이 악의적인 동작을 하는지 알아보는 건 불가능할 듯 싶습니다. 일종의 halting problem이려나요? ;

daybreaker (2006-05-08 16:08:06)에 의해 마지막으로 수정

문제의 답은 우리 안에 있다.
내면에 귀를 기울여 보자.

21

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

daybreaker 작성:

오호.. 요즘 Programming Language 시간에 하는 내용들이 나오는군요;; 저번 중간고사 범위가 lexical/syntatic analysis였다는...-_-;;

확실히, php 코드를 분석해서 그것이 악의적인 동작을 하는지 알아보는 건 불가능할 듯 싶습니다. 일종의 halting problem이려나요? ;

그걸 전부 parsing해서 검사하면 당연히 불가능하겠죠...

그렇지만 그냥 텍스트 안에 문제가 될 소지가 있는 명령어들이 포함되어 있는지의 체크는 굉장히 쉽지 않을까 합니다. smile

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

22

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

daybreaker 작성:

오호.. 요즘 Programming Language 시간에 하는 내용들이 나오는군요;; 저번 중간고사 범위가 lexical/syntatic analysis였다는...-_-;;

확실히, php 코드를 분석해서 그것이 악의적인 동작을 하는지 알아보는 건 불가능할 듯 싶습니다. 일종의 halting problem이려나요? ;

PL 강의만으로 완전히 이해하는 것은 무리지요.
compiler를 들어보셔야 ㅎㅎ

23

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

PAPACHA 작성:

PL 강의만으로 완전히 이해하는 것은 무리지요.
compiler를 들어보셔야 ㅎㅎ

덜덜덜;;
전설의 컴파일러...;;;

PL은 컴파일러의 선행 과목 정도니까 아무래도 더 깊이 있게 알려면 컴파일러를 들어야겠죠.

문제의 답은 우리 안에 있다.
내면에 귀를 기울여 보자.

24

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

inureyes 작성:
daybreaker 작성:

오호.. 요즘 Programming Language 시간에 하는 내용들이 나오는군요;; 저번 중간고사 범위가 lexical/syntatic analysis였다는...-_-;;

확실히, php 코드를 분석해서 그것이 악의적인 동작을 하는지 알아보는 건 불가능할 듯 싶습니다. 일종의 halting problem이려나요? ;

그걸 전부 parsing해서 검사하면 당연히 불가능하겠죠...

그렇지만 그냥 텍스트 안에 문제가 될 소지가 있는 명령어들이 포함되어 있는지의 체크는 굉장히 쉽지 않을까 합니다. smile

문제는 의도적으로 악의가 있는 경우입니다. 의도적이기 때문에 체크 루틴을 회피할 수 있는 방법을 사용한다는 것이지요.

25

답글: 혹시라도 플러그인과 같은 것들이 가질 수 있는 문제

daybreaker 작성:

덜덜덜;;
전설의 컴파일러...;;;

PL은 컴파일러의 선행 과목 정도니까 아무래도 더 깊이 있게 알려면 컴파일러를 들어야겠죠.

...저의 경우는 듣고나서 더 모르게 되어버렸습니다 =_=;

어디든 사람 상대하는 부분이 제일 어렵다는 진리를 깨닫게 해준 과목이었죠. (컴파일러에 들어가는 코드는 사람이 짜니까요)

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'