妄想まとめ

研究とかWebセキュとか時事ネタとか。 @kazu1130_h

Memcached

前々から気になってたmemcachedについて少しお勉強。

 

memcached - Wikipedia

http://ja.wikipedia.org/wiki/Memcached

memcached - a distributed memory object caching system

http://memcached.org/

 

 

要するにメモリ上に置いとくデータベースみたいなモノ。

set hoge 0 0 4

fuga

>STORED

 

get hoge

>VALUE hoge 0 4

>fuga

>END

 

みたいなの。詳しくはここら辺を参考に。

 

[memcached]  - Life with IT

http://l-w-i.net/t/memcached/command_001.txt

第1回 memcachedの基本

http://gihyo.jp/dev/feature/01/memcached/0001

 

 

 

で、この辺色々漁ってるときに、memcachedサーバ立てて分散させたWebサーバ間でセッションを共有すれば色々幸せになるんじゃね? そうじゃなくてもメモリ上にセッション置いとけば早いし適当に消えるしいいんじゃね? ってのをこの辺で読んで

 

memcachedでPHPのSession管理

http://www.trajectory.jp/tech/php/memcachesession.php

 

 

さらにこの手の物とWebを組み合わせた時に高確率で起こるInjection的な脆弱性が例に漏れずあるようで、memcached Inectionに関してまとめた文章が出てる事を知る。

 

Memcached Injection - NTT Communications -

http://www.ntt.com/icto/security/images/sr20080311.pdf

 

 

この文章だと、最後に「memcachedのキー名に汚染データを入れる必要がある事は稀である」とか書いてあるし、そもそも実験結果でPHPのライブラリがあがってないしで、これはもしや…… と思って手元環境で実験。

 

セッションならkeyにセッションID(PHPだとAdaptionあるから外部から自由にいじれる可能性が高い)を使っても不思議じゃないし、対策されてなければ夢が広がるが……。

結果、PHPではセッションIDに改行文字とか入れてもセッションそのものが成立せず(振りなおされる)、$memcache_obj->set($_GET["key"],$_GET["value"])  で無理矢理keyにInjectionさせてみても改行文字は_に変換されて、結局memcached Injectionは出来ませんでしたとさ。

 

因みに環境はこんな感じ。

PHP5.3.10

memcached 1.4.13-0ubuntu2

php5-memcached 1.0.2-2

 

 

他、memcached関連でググってて見つけた面白そうなのは

 

Memcached に潜むセキュリティホール

http://security.slashdot.jp/story/10/08/10/0052240/Memcached-%E3%81%AB%E6%BD%9C%E3%82%80%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%83%9B%E3%83%BC%E3%83%AB

 

 

で紹介されてる、アクセス制御の不備的な事。

memcachedはアクセス制御の方法がIPアドレスベースのものだから、そこの設定が適当なままネット上からアクセス出来る所に置いとくと高確率で爆死する。ログインもパスワードも無いってシンプルすぎる気が……。

 

それに、一台一台ホワイトリストで指定するの面倒だから192.168.1.xとかみたいにアクセス制御すると思うんだけど、そういう指定方法だとうっかり共有サーバのIPまで含めちゃった、とかが普通に起こりそう。プロトコルがテキストベースで簡単な上、既にmemcachedサーバにつなげて丸ごとダンプとるツールがgitにあがってるし、ひとたび狙われたら……。

 

今後更にこの辺の問題が起きるんじゃないかなぁ……と思いました。(小学生並みの感想)

 

 

 

追記

調べてたらPHPではmemcacheとmemcachedという凄く分かり難い何かがあるらしい。しかも昔はmemcachedでは渡されたkeyをエスケープしてなかったらしい。でも今回の結果を見る限り、今は対策済み?