- From: Sangwhan Moon <sangwhan.moon@hanmail.net>
- Date: Fri, 27 Jul 2012 01:13:13 +0900
- To: HTML WG <public-html-ig-ko@w3.org>
안녕하세요. 우선 한가지... 대부분 리스트에 가입된 사람들인 만큼, reply-all은 안하셔도 됩니다. :-) (그렇게 하시면 메일이 두 통씩 옵니다...) 여기부터는 개인적인 사견이며 고용주와는 무관함을 미리 밝힙니다. >>>>> 예. 재밌네요~ 애플이 구글이 독립적으로 자체 브라우저 엔진을 사용하는 것을 허용하지 않는걸까요?? 궁금하네요~^^ 구글이라서도, 브라우저 엔진이라서가 아니라 가이드라인상의 형평성으로 협의가 되지 않았던게 아닐까 의심됩니다. 출처: https://developer.apple.com/appstore/resources/approval/guidelines.html#damage-device 2.7 Apps that download code in any way or form will be rejected 2.8 Apps that install or launch other executable code will be rejected 브라우저 엔진일 경우 JIT가 되지 않더라도 2.7 과 2.8을 어길 수 밖에 없게 됩니다. 해당 규칙이 생긴 정확한 근거는 애플이 아닌 이상 알 수 없습니다만, review가 끝난 어플리케이션이 다운로드된 코드를 이용하여 다형성을 갖게 될 경우 review 과정 자체를 무색하게 만들어버리는 문제가 가장 크지 않았을까 의심됩니다. (아울러 JIT가 가능하다면 JIT spraying이라는 공격의 대상이 될 수 있습니다. 이건 그냥 여담입니다.) 브라우저의 경우는 단순 브라우저도 될 수 있지만, 성인컨텐츠를 보기 위한 창구도 될 수 고, 게임도 될 수 있는 다형성이 있는 어플리케이션이 될 수 있기 때문에 문제가 되는게 아닐까 짐작해봅니다. (단적인 예로, Opera Mini는 18세 미만 관람불가입니다 [...]) HTML5 와는 전혀 무관한 내용입니다만, 아래 토론에 대해서 첨언을 하자면... *** HTML5에만 관심이 있으신 분은 여기서 그만 읽으셔도 됩니다. *** > 제가 아는 지식으로는 윈도 시스템의 경우(다른 OS는 모르겠구요, iOS는 허용 안되는 것 같구요) 영역침범이 가능합니다. 1) Windows는 영역 침범이 가능하다는건 반은 맞고 반은 안맞습니다. "요새 사용하는 Windows"는 Debugging API를 이용하지 않으면 intra-process intrusion은 불가능합니다. 적어도 확인 된 바로는 Windows NT 3.51 이후는 전부 안됩니다. Windows 9x는 memory protection model이 흥미로운데, userland는 대부분 가능했던걸로 기억하고 시스템도 일부 가능했던걸로 기억합니다. (15년은 족히 된 기억이라 세부적인 내용은 정확히 기억이 안납니다.) iOS는 process별로 sandbox에 들어가기 때문에 memory protection을 제쳐두더라도 침범이 안됩니다. > 그래서, 관리자 권한 획득하는 웜들이 권한을 획득할 때, 시스템이 30초후 리부팅 됩니다. 와 같은 메시지가 뜨기도 합니다. 2) 관리자 권한을 획득하는 웜 중 시스템이 30초 후에 재부팅 되는 웜은 RPC DCOM 인터페이스의 악성 입력값을 전달하는 방법으로 buffer overflow를 유발, RPC DCOM 서비스가 죽게 함으로써 윈도우가 복구 불가능한 상태가 되어 재부팅을 발생시키는 형태로 동작을 하며, 메모리 침범과는 무관합니다. >>> 윈도 시스템이 가장 곤욕을 치루는 것이 데이터 영역의 buffer를 overflow하게 write해서 실 >>> 행영역을 침범하게 한후, >>> >>> 그 (데이터 영역에서 침범한) 코드가 실행되게하는 수법(기술?)입니다. 그래서 주기적인 패치를 >>> 통해 그런 hole을 막고 있죠. 3) 일반적으로 buffer overflow를 이용해서 의도하지 않은 코드를 실행하는 것은 stack smashing 이라고 하는데 언급된 "실행역역을 침범한다"는건 맞지 않습니다. 가장 간단한 예로는 크기가 입력값을 고정된 크기의 n을 받으나 입력값을 검증하지 않는 함수를 대상으로 총 크기가 n + stack frame + ra가 되도록 (code + address)를 덮어써서 실행이 되도록 하는 형태입니다. 비전공자가 구르면서 줏어 배운걸 말로 설명해서 조금 난해할 수 있습니다만... 이건 아주 기본적인 접근 방식이며, DEP나 stack protection이 있을 경우에 이 정도로 간단하지는 않습니다. 다만... IG와 무관한 내용이기 때문에 이 이상은 언급하지 않겠습니다. (아울러 아키텍쳐별로 접근 방법이 다릅니다.) >> 다른 프로그램이 이미 사용하고 있다면 crash가 나지 않을까요? 4) 아래 언급하셨듯 memory protection이 있는 OS에서 허가되지 않은 메모리 영역에 침범을 하려고 하면 *접근하려한* 프로세스가 죽게 되어있습니다. 임시 보관함에 퀘퀘하게 발효중이던걸 이제야 보내게 되네요. 쓸데없이 길어져서 죄송합니다. 감사합니다. 문상환 배상 On Jul 3, 2012, at 5:24 PM, Bong, Jèwon wrote: > 네, 이원석님 > > 제가 아는 지식으로는 윈도 시스템의 경우(다른 OS는 모르겠구요, iOS는 허용 안되는 것 같구요) 영역침범이 가능합니다. > > 그래서, 관리자 권한 획득하는 웜들이 권한을 획득할 때, 시스템이 30초후 리부팅 됩니다. 와 같은 메시지가 뜨기도 합니다. > > 혹시 전문가분 계시면 조언해 주세요. > > 봉 재 원(Jèwon Bong) > Sent from my iPhone. > > http://j1act.com/applist > > On 2012. 7. 3., at 16:40, Wonsuk Lee <wonsuk11.lee@samsung.com> wrote: > >> 안녕하세요. 재원님. >> >> >>> -----Original Message----- >>> From: Bong봉Jèwon재원 [mailto:jw@j1act.com] >>> Sent: Saturday, June 30, 2012 12:34 AM >>> To: Premist Lee >>> Cc: Wonsuk Lee; mixed; Younggyo Seo; Sangwhan Moon; HTML WG >>> Subject: Re: Benchmarks Shows That iOS 6 Safari is 17.2% Faster Than iOS 5 >>> >>> 첫 글을 써봅니다. ^^ >>> >>> 조금 근원적인 시야에서 본다면.. >>> >>> 제가 아는 짧은 보안지식으로는 실행영역과 데이터 영역을 격리시키는 가장 큰 이유는 >>> >>> 흔히 말하는 버퍼오버플로우 공격을 막기위해서 입니다. >>> >>> 애플에서 그 부분에 신경을 쓰는 것 같습니다. >>> >>> 윈도 시스템이 가장 곤욕을 치루는 것이 데이터 영역의 buffer를 overflow하게 write해서 실 >>> 행영역을 침범하게 한후, >>> >>> 그 (데이터 영역에서 침범한) 코드가 실행되게하는 수법(기술?)입니다. 그래서 주기적인 패치를 >>> 통해 그런 hole을 막고 있죠. >> >> 제가 정확히 몰라서 그런데, OS에서 실행영역을 침범하는 것을 허용하나요? >> 이런 것이 문제가 된다면 OS가 데이터 영역을 침범하는 것을 근본적으로 막으면 될 것 같아서 여쭤봅니다. >> >> 그리고 데이터 영역에서 실행영역을 침범한다면 아마도 데이터 영역의 주소와 연결이 되는 실행영역 일 것 같은데, >> 다른 프로그램이 이미 사용하고 있다면 crash가 나지 않을까요? >> >> 제가 아는 지식으로 질문을 해봅니다^^ >> >> >> 이원석 드림. >> >> >>> 다 아시는 내용이라면 젠틀하게 패스~ 부탁드립니다. ^^ >>> >>> 봉 재 원 >>> http://JewonAgency.com >>> >>> >>> 2012. 6. 29., 오후 11:15, Premist Lee 작성: >>> >>>> 네, 또한 사파리에서 사용되는 Nitro 엔진도 보안 상의 문제로 애플이 막아놓은 상태입니다. >>> 벤치마크 해 보니 속도가 약간 느리더군요. >>>> >>>> 아 그리고 구글이 SPDY 지원을 넣긴 넣었더군요. 래핑만 한 건 아닌 것 같네요; >>>> >>>> >>>> -- >>>> Minku Lee >>>> http://si.mpli.st/ >>>> http://twitter.com/premist >>>> http://fb.me/premist.lee >>>> >>>> >>>> On Jun 29, 2012, at 3:01 AM, Wonsuk Lee <wonsuk73@gmail.com> wrote: >>>> >>>>> 안녕하세요~ >>>>> >>>>> 예. 재밌네요~ 애플이 구글이 독립적으로 자체 브라우저 엔진을 사용하는 것을 허용하지 않는 >>> 걸까요?? 궁금하네요~^^ >>>>> >>>>> 이원석 드림. >>>>> >>>>> 2012년 6월 29일 오전 8:48, mixed <i.nevalose@gmail.com>님의 말: >>>>>> 안녕하세요. 전용우입니다. >>>>>> 전에 문상환님이 iOS에서 크롬이 나오는것에 회의적이며 나와도 반쪽 짜리 크롬이 나올것이 >>> 라고 하셨는데 정확하시네요. >>>>>> >>>>>> 오늘 본 트윗인데 iOS버전의 크롬이 나오는데 렌더링/JS엔진은 iOS에서 제공하는 걸 쓴다고 >>> 하네요. >>>>>> 거의 랩핑한 수준이네요. >>>>>> >>>>>> -------------- >>>>>> @viviancromwell: Chrome for iOS provides the same browsing experience >>> you've >>>>>> on desktop/Android. Rendering/JS engine are provided by iOS so it >>> doesn't >>>>>> use V8 >>>>>> ------------- >>>>>> >>>>>> >>>>>> On Friday, June 15, 2012, mixed wrote: >>>>>>> >>>>>>> 안녕하세요. 전용우입니다. >>>>>>> >>>>>>> 제가 이해하는데 구멍이 있던 부분이 sandbox부분이였는데 쉽게 설명해주셔서 이해가 잘 >>> 됐습니다. >>>>>>> >>>>>>> 감사합니다.^^ >>>>>>> >>>>>>> >>>>>>> 2012/6/15 Younggyo Seo <seo.younggyo@gmail.com> >>>>>>> >>>>>>> 안녕하세요. >>>>>>> >>>>>>> 코드로 설명해 주시니 명확하게 이해되네요. >>>>>>> 감사합니다. >>>>>>> >>>>>>> 서영교 드림 >>>>>>> >>>>>>> 2012년 6월 15일 오후 2:59, Sangwhan Moon <sangwhan.moon@hanmail.net>님의 >>> 말: >>>>>>> >>>>>>> 안녕하세요. >>>>>>> >>>>>>> 얼마전에 언급된 "크롬이 아이패드로 나온다" 였던가의 메일에서 에서 >>>>>>> 크롬 포팅 가능성에 대해서 회의적인 입장으로 간단하게 언급했습니다만... >>>>>>> >>>>>>> On Jun 14, 2012, at 11:10 PM, Wonsuk Lee wrote: >>>>>>> >>>>>>>> 안녕하세요. >>>>>>>> 먼저 좋은 답변 감사합니다~ >>>>>>>> 아래와 같이 inline comment를 달았습니다~ >>>>>>>> >>>>>>>> >>>>>>>> 2012년 6월 14일 오후 2:25, Younggyo Seo <seo.younggyo@gmail.com>님의 말: >>>>>>>>> 안녕하세요. 오비고 서영교 입니다. >>>>>>>>> >>>>>>>>> 저도 궁금해서 좀 더 구글링을 해봤습니다. >>>>>>>>> 전용우 그룹장님 의견에 추가하여, >>>>>>>>> >>>>>>>>> 일반적인 Native Application은 크게 코드 영역과 실행 영역으로 나눌 수 있을 것이 >>> 고, 컴파일 이후에는 코드 영영의 >>>>>>>>> 변경은 이루어 지지 않을 것 입니다. >>>>>>> >>>>>>> 이 부분에 내용이 조금 틀린 부분이 있습니다. text 와 data 두가지로 크게 나뉘는데, >>>>>>> text가 code라고 불리기도 합니다. (대부분의 disassembler나 debugger는 text라는 >>>>>>> 명칭을 사용합니다) data는 말 그대로 data입니다. >>>>>>> >>>>>>> "실행이 가능한" segment라고 하면 마찬가지로 text가 아닐까 생각됩니다. >>>>>>> >>>>>>>> 그런데 코드영역과 실행영역이 정확히 어떤 것을 이야기 하는 것인가요? >>>>>>>>> 하지만 JIT이 동작하기 위해서는 Native Application이 실행된 다음, 실시간으로 코 >>> 드 영역이 생성되어 져야 >>>>>>>>> 합니다. >>>>>>>>> 그러나 iOS에서는 Application의 실행 중, 코드 영역을 생성하여 실행할 수 없도록하 >>> 는 보안 정책을 가지고 있다고 >>>>>>>>> 합니다. >>>>>>>>> - iOS 전문가님의 의견 필요 ^^ >>>>>>> >>>>>>> 조금 더 정확히는 mmap으로 시스템으로 부터 실행 가능한 페이지 (PROT_EXEC)를 >>>>>>> 할당받아서 사용합니다. 이 접근을 사용하는 것이 Sandbox 안에서는 불가능합니다. >>>>>>> >>>>>>> 예> void* executable_code_page = mmap(NULL, 8192, >>>>>>> PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); >>>>>>> >>>>>>> ARM의 경우.. 여기에서 executable_code_page를 32-bit align한 후 실행하고 싶은 >>>>>>> 코드를 전부 넣고, 마지막에 BX R14을 넣어준 다음, 호출하면 주입한 코드가 전부 >>>>>>> 실행이 된 다음에 반환됩니다. >>>>>>> >>>>>>> 물론 아키텍쳐에 따라서 접근은 달리 해야 합니다. 자세한 내용은 책이 아닌 관계로 >>>>>>> 생략하겠습니다. >>>>>>> >>>>>>>>> 애플에서는 이 보안 정책을 Safari 에서만 예외가 가능하도록 처리해 놓았기 때문에, >>> Safari에서만 nitro가 동작가능한 >>>>>>>>> 것 >>>>>>>>> 같습니다. >>>>>>> >>>>>>> 애플에서 내보내는 Safari는 Sandbox안에서 돌아가지 않기 때문에 가능한 것입니다. >>>>>>> App store에서 다운로드 받은 어플리케이션은 전부 Sandbox context 안에서 실행되기 >>>>>>> 때문에 그 안에서 dynamic link된 UIKit.framework에서 UIWebView를 사용하게 될 >>>>>>> 경우 해당 Webview에서 사용하는 Webkit의 실행 context가 Sandbox안에 있기 때문에 >>>>>>> 위와 같이 실행 가능한 코드를 주입하는 것이 불가능합니다. >>>>>>> >>>>>>> 코드를 열어보지는 않았습니다만, 아마 자바스크립트 엔진에서 sandbox 안에 있는지 또는 >>>>>>> UIWebView에서 호출되었는지 assert 후 실패할 경우 interpreter모드로 fallback을 >>> 할 것으로 >>>>>>> 추정됩니다. 만약에 UIWebView를 jailbreak된 상태에서 사용할 경우 JIT가 동작한다면 >>> 후자 >>>>>>> 일 것이고, jailbreak를 했어도 JIT가 비활성화되어 있다면 전자로 생각하시면 됩니다. >>>>>>> >>>>>>> (여담으로 전자가 구현하기 쉽고 오류의 여지가 상대적으로 적기 때문에 저라면 전자로 했 >>> 을겁니다.) >>>>>>> >>>>>>> 단적인 예로... Safari는 Sandbox안에 있지 않았었기 때문에 Freetype 취약점을 이용 >>> 한 >>>>>>> Jailbreakme 3.0이 가능했던것입니다. >>>>>>> >>>>>>>>> 또한 이런 이유로 Webkit2가 Safari on iOS 에에 적용되면 WebView에서도 nitro의 >>> 사용이 가능하다고 >>>>>>>>> 말하고 있는 것 같습니다. >>>>>>>>> - Webkit2의 경우 UI와 엔진이 프로세스로 분리되어 동작하고 있는 것으로 압니다. >>>>>>>> >>>>>>>> Webkit2에서는 UI 프로세스와 Web 프로세스로 분리되어 있기는 합니다만 이렇게 되는 >>> 경우에 왜 Nitro 적용이 >>>>>>>> 가능한지는 정확히 이해가 되지 않습니다^^; >>>>>>>> 혹시 좀더 자세히 설명이 가능할 까요? >>>>>>> >>>>>>> 위에 설명이 되었을것이라고 생각됩니다. (고용주와 관계 상 Webkit에 대해서 더 자세하 >>> 게 >>>>>>> 이야기하지 못하는 점, 양해 바랍니다.) >>>>>>> >>>>>>> 애플에서 보안 정책을 갑자기 변경하지 않는 이상, 상기와 같은 이유로 iOS에 Opera >>> Mobile이나 >>>>>>> Firefox, Chromium이 나오더라도 반쪽짜리 제품이 나올것이라고 생각됩니다. >>>>>>> >>>>>>> (추가적으로 App store review guideline 현행 버전에 의하면 additional >>> executable code에 >>>>>>> 대해서 명시적으로 언급이 되어 있기 때문에, 그게 바뀌기 전까지는 브라우저도 게임기 에 >>> 뮬레이터도 >>>>>>> 전부 정책 변경이 이루어질때까지는 불가능합니다.) >>>>>>> >>>>>>> 감사합니다. >>>>>>> 문상환 배상 >>>>>>> >>>>>>>>> >>>>>>>>> http://code.google.com/p/v8/issues/detail?id=1312 >>>>>>>>> - I was told that the problem with getting V8 to run on iOS was the >>>>>>>>> fact >>>>>>>>> that JIT compilation could not be supported due to Apple disabling >>>>>>>>> writable >>>>>>>>> and executable memory regions. >>>>>>>>> >>>>>>>>> http://news.ycombinator.com/item?id=2317804 >>>>>>>>> - A JIT works by compiling some chunk of code into a section of >>>>>>>>> executable >>>>>>>>> memory, then jumping to that location. As I understand it, iOS >>> hasn't >>>>>>>>> previously allowed execution of code from "data memory" (various >>> people >>>>>>>>> were >>>>>>>>> curious about this very thing when it was announced they were >>> shipping >>>>>>>>> a >>>>>>>>> JIT). >>>>>>>>> >>>>>>>>> 서영교 드림 >>>>>>>>> >>>>>>>>> 2012년 6월 14일 오전 9:37, mixed <i.nevalose@gmail.com>님의 말: >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ========================================= >>>>> 이 원 석 (Wonsuk, Lee) / Principal Engineer, Ph.D >>>>> SAMSUNG ELECTRONICS Co., LTD. (三星電子) >>>>> Mobile: +82-10-5800-3997 >>>>> E-mail: wonsuk11.lee@samsung.com, wonsuk73@gmail.com >>>>> http://www.wonsuk73.com/, twitter: @wonsuk73 >>>>> ----------------------------------------- >>>>> Inspire the World, Create the Future !!! >>>>> ========================================= >>> >>> >>> >>> 봉재원(Jèwon Bong) >>> jw@j1act.com >>> >>> http://j1act.com/applist >>
Received on Thursday, 26 July 2012 16:14:08 UTC