OpenLook

이더넷이나 802.11 네트워크에서 하위 레이어의 프로토콜 주소를 찾기 위해 사용되는 ARP의 구현에 문제점이 발견되어서 보안 권고가 발표되었습니다.

http://lists.freebsd.org/pipermail/freebsd-security/2003-September/000989.html

구체적인 문제점으로는, 같은 네트워크에 물려있는 악의의 공격자가 스푸핑을 하면서 계속 ARP를 엄청나게 많이 때리면 자원이 고갈되면서 커널 패닉이 나는 것인데, 벌써 10년도 넘은 소스에서 발견된 문제점이라, BSD계열 전체에 적용됩니다. (이번 버그는 Apple에서 발견하였습니다.)

믿을 수 없는 공중 네트워크에서 혹시 사용하신다면 얼른 업데이트하세요~ 흐흐 패치할 수 없다면, static arp를 사용하거나 선을 뽑아버리는 방법이 있다고 합니다. -ㅁ-;;

어제 대충 소식만 전했던 이무라씨의 파일시스템 멀티바이트 패치(사실은 iconv패치 쪽은 2바이트 전용) 체험담을 자세히 소개합니다. 흐흐

우선, 이 패치는 벌써 일본에서는 많이 쓰고 있다고 합니다. 200명 넘게 아무 문제 없이 쓰고 있다고 하니 안정성에서는 크게 걱정할 필요없을 것 같네요. 저도 사실은 9월 1일자 커널에다가 모듈만 컴파일해서 넣었는데도 잘 도는군요 크크;

패치하는 방법은 다운로드 받은 뒤에, /usr/src에서 patch -p0 <kiconv-5_current-20030921.diff하시면 되는데, 전부 성공해야합니다. 성공했는지 여부는 출력을 봐도 되지만 find . -name ‘*.rej’같은 명령으로도 검색하실 수 있구요. 그 뒤에, world가 옛날 소스라면 make world를 한 번 하시고, 최근 소스 그대로라면 /usr/src/lib/libkiconv에서 make install하고 /usr/src/include에서 make install하고 make kernel하시면 됩니다. (libkern이 바뀌었기 때문에 커널 전체 빌드하지 않으면 잘 안 됩니다. 흐물..) 그 다음에는 보통 커널 컴파일하듯 리붓 한판 하시고, 이제 msdosfs를 마운트하면 됩니다. 요렇게..

그러면 이제 /d가 euc-kr로 나오는 것을 볼 수 있습니다. 흐흐

간단하게 구현 내용을 보면, 어제 블로그에서 쓴 것이 잘못되었는데요 흐흐.. libiconv를 무시한 것이 아니라, libiconv에 xlat16 컨버터를 추가하고, libkiconv라는 유저랜드측 라이브러리가 mount_msdosfs같은 마운트 프로그램들에서 libiconv.so에서 16비트 컨버터 테이블을 만든 다음에 sysctl로 libiconv.ko에 전달해 주는 구조로 되어있습니다. 그래서, 결국은 다른 패치들도 msdosfs_iconv.ko등 _iconv가 달려있는 커널 모듈이 올라오면 컨버터가 전부 libiconv.ko를 쓰도록 패치됩니다. 제대로 된 구조죠 흐흐.

일단 Shift-JIS, Big5, GBK, EUC-KR같은 것 쓰는데는 큰 문제가 없다만, 문제는 16비트 테이블로 해결이 안 되는 UTF-8이나 EUC-JP같은 것들인데, EUC-JP는 파일시스템에서는 거의 안 쓰니까 빼고, UTF-8은 전에 했던 애플 패치를 한번 이무라씨의 패치와 합쳐볼 생각입니다. 흐흐. 어제 UTF-8패치 만들어 놨던 걸 메일링리스트에 올렸더니 trhodes@가 같이 Darwin msdosfs 머지 작업을 하자고 메일을 보내왔는데, 사실 유니코드 컨버트 외에 dirty mark같은 건 전혀 몰라서 -.,-; 수준 맞춰서 같이 할 수 있을 지 모르겠군요 으흐흐;

전에 Blog0308/MsDosFsUtf8에서 혼자서 해놓고 좋다 그러고 있었던 패치에서 훨씬 더 나아간 전역적인 커널 패치를 류이치로 이무라씨가 방금 공개했습니다. 커헉~ 저 많은 패치를 소문없이 해버리다니 =3 =33

이무라씨의 패치 내용은 기존에 있던 libiconv 커널 모듈을 완전히 무시해버리고 새로 kiconv라는 라이브러리를 만들어서 kiconv를 이용하도록 cd9660, msdosfs, ntfs 커널 모듈에 패치해서 각각 CD9660_ICONV, MSDOSFS_ICONV, NTFS_ICONV 커널 옵션을 주면 iconv를 사용하도록 한다고 합니다. libiconv는 완전히 커널에서 다 해결보려고 한 반면에, kiconv는 유저랜드 라이브러리(보통 GNU libiconv)를 이용해서 테이블을 만든 뒤에, 테이블을 sysctl로 복사해서 쓴다고 합니다. kiconv의 방법은 빤히 한계가 드러나고 문제가 있긴 하지만.. libiconv 커널모듈도 디자인이 잘 된 편은 아니기에.. 임시방편으로는 뭐 괜찮기도 하겠네요 (-.-;;;;)

• 패치 내용: http://www.ryu16.org/FreeBSD/kiconv/kiconv-5_current-20030921.diff

• 메일 내용: http://lists.freebsd.org/pipermail/freebsd-i18n/2003-September/000034.html

시간날 때 적용해 보고 더 자세한 것은 내일 또~ 이히..