シェルスクリプトの平文パスワードをセキュアにする方法 - 余白の書きなぐり
追記: (2015/8/3) 大量のはてブが付いたので 続き を書きました。 sshを使用している人は文字列を手軽に暗号化・復号化できるという話。 このテクニックを使えば色々セキュアになるのでおすすめ。 今回はシェルスクリプト中の平文パスワードをセキュアに代替する。 平文パスワードはやめよう シェルスクリプト中でパスワードが必要になったとき、 とりあえず平文で書いてしまいがち。 #!/bin/sh PASSWORD="hoge" これをセキュアにしたい。 面倒くさいのは嫌なので、なるべく手持ちのツールで暗号化、復号化したい。 ssh用の rsa 秘密鍵と、openssl(大抵の環境に入っている)を使って改善しよう。 秘密鍵の準備 パスワードを暗号化するにあたって、秘密鍵を使用する． sshを常用している場合は ~/.ssh/id_rsa という秘密鍵が存在するだろう。 もし秘密鍵が無ければ
ウェブアプリにおけるBash脆弱性の即死条件 #ShellShock - めもおきば
条件1. /bin/shの実体がbashのディストリビューション RHEL CentOS Scientific Linux Fedora Amazon Linux openSUSE Arch Linux (自ら設定した場合: Debian, Ubuntu) 条件2. 動作環境 CGI (レンタルサーバでありがちなCGIモードのPHP等も含む) Passenger(Ruby) 条件3. プログラム内容 Passengerは全死亡 *1 systemや `command`、 '| /usr/lib/sendmail' などで外部コマンド実行 *2 PHPのmailやmb_send_mail、その他フレームワーク等を介したメール送信 *3 以下は条件1が不要 明示的にbashを呼ぶ 先頭で #!/bin/bash や #!/usr/bin/env bash しているプログラムを実行 (rbenv
Perl CGI 中での Bash "Shellshock" 脆弱性 (CVE-2014-6721) 影響有無を確認した - [ぴ](2014-09-29)
引数ありで、それを引用符で囲っている場合のみ影響を受けることが確認できた。 なお、 system LIST system PROGRAM LIST (略) スカラの引数が一つだけの場合、引数はシェルのメタ文字をチェックされ、もし あればパースのために引数全体がシステムコマンドシェル (これは Unix プラットフォームでは /bin/sh -c ですが、他のプラットフォームでは 異なります)に渡されます。 シェルのメタ文字がなかった場合、引数は単語に分解されて直接 execvp に 渡されます; この方がより効率的です。 [Perlの組み込み関数 system の翻訳より引用] によると、引用符があるかどうかではなく、メタ文字があるかどうかが生死を分けるポイントとのこと。 使用したコード sstest-sh.cgi #!/bin/sh echo "Content-type: text/pl
](https://cdn-ak-scissors.b.st-hatena.com/image/square/d228e8be070c32c738781e15c25aeb18f4dc6807/height=288;version=1;width=512/https%3A%2F%2Fpmakino.jp%2Ftdiary%2Ftheme%2Fogimage.png)
bashにおける脆弱性「Shellshock」について
2014/09/26 コース：元祖こってり 「元祖こってり」記事はネットエージェント旧ブログ[netagent-blog.jp]に掲載されていた記事であり、現在ネットエージェントに在籍していないライターの記事も含みます。 bashにおける脆弱性「Shellshock」について LinuxやMac OS XなどのUNIX系OSで広く使用されているbashに見つかった脆弱性(Shellshockと呼ばれています)が先日から話題になっています。 弊社でもこのbashの脆弱性について調査を行いました。 ■概要 環境変数に特定の文字列を設定するだけでその環境変数内の文字列をシェルが関数として実行してしまいます。 シェルを通じてコマンド等を実行する幅広い環境で影響がありますが、特に顕著に影響を受けるのはCGI等のWebアプリケーション環境です。 CGIをはじめとするWebアプリケーションではWebブラ
ファイアウォール内のサーバに対するShellshockを利用した攻撃 - 葉っぱ日記
2014-09-27: 該当サイト上にXSSがなくても攻撃可能であることが id:mayuki さんのコメントで判明しましたので全面的に書き直しました。ファイアウォール内であっても攻撃者はファイアウォール内のShellshock攻撃が通用するCGIのURLがわかっているだけで攻撃可能ですので早急に対応が必要です！会社のブログにも書いてますが、ファイアウォール内に置いてあるサーバで攻撃者が直接アクセスできないからといってbashの更新を怠っていると、条件によっては攻撃が可能となります。 条件としては、 そのサーバにはシェルを経由して外部コマンドを起動するCGI等が動いている(通常のShellshockの攻撃と同条件) 攻撃者がそのURLを事前に知っている(あるいは推測可能) となります。 攻撃者は、ユーザーを罠URLへ誘導し、以下のようなJavaScriptを罠ページ上で動かし、攻撃対象のW
bashの脆弱性(CVE-2014-6271) #ShellShock の関連リンクをまとめてみた - piyolog
bashに脆弱性が確認されたとして騒ぎになっています。ここではCVE-2014-6271に関する情報をまとめます。 #記載内容について、誤っている、追記した方がいい等情報がございましたら@piyokangoまでご連絡お願いします。 脆弱性情報 脆弱性の愛称 ShellShock Bashbug CVE番号 Bash周りで発行されているCVEは6つ。その内詳細が不明なのが2つ。(CVE-2014-6277,CVE-2014-6278) CVE 発見者 想定脅威 特記 CVE-2014-6271 Stephane Chazelas氏 任意のコード実行 ShellShockの発端となったバグ。 CVE-2014-7169 Tavis Ormandy氏 任意のコード実行 CVE-2014-6271修正漏れによる脆弱性 CVE-2014-7186 Redhat DoS メモリ破壊(Out-of-Bo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
