シェルで変数のインクリメントに expr を使うと100倍遅い件
シェルプログラミングにおいて、ループカウンタなどをインクリメントするとき、どのようにしますか？ いきなりですがサンプルから。 #!/bin/bash COUNT=0 while [ $COUNT -lt 1000 ]; do # 何かの処理 COUNT=`expr $COUNT + 1` # COUNT をインクリメント done expr コマンドを使う？ シェルプログラミングの入門記事などを見ると、変数のインクリメントに上記のような COUNT=`expr $COUNT + 1` を用いているものが多くあります。 しかし、この書き方は とても遅い です。空のループを1000回繰り返すだけでも手元の mac (Core i7) で約2秒もかかってしまいました。
インフラエンジニアとしてよく使うコマンド集 - Qiita
私がよく使うコマンド集となります。 参考に頂けたら幸いです。 随時更新するかと思います。 コマンドを打つ前に覚えておく事 ①サーバに負荷がかかるコマンドを打つ場合、下記をコマンドの先頭に付けましょう $ ionice -c 2 -n 7 nice -n 19 # -c 2：ディスクI/Oの実行優先度をベストエフォートで実行 # -n 7：さらにこのコマンドの優先度を低くする # -n 19：プロセスの実行優先度を一番低くする
bashの脆弱性を抱えるNASへの攻撃、日本や韓国が標的に
LinuxなどUNIX系OSで使われているシェルの「bash」に極めて深刻な脆弱性が発覚した問題で、セキュリティ企業の米FireEyeは現地時間の10月1日、日本や韓国、米国のNAS（Network Attached Storage）システムを標的する攻撃を確認したと発表した。 この問題は「Shellshock」と呼ばれ、bashで特定の細工を施した環境変数を処理する方法に起因する脆弱性が複数存在する。脆弱性を悪用されると、アプリケーションの権限で任意のOSコマンドが実行されてしまう恐れがある。一般的な設定でネットワークを介して容易に悪用できるとされ、2014年4月に発覚したOpenSSLの脆弱性（Heartbleed）を超える危険だとの指摘も聞かれる。 FireEyeが確認した攻撃では日本や韓国、米国の大学や研究機関で利用されているQNAP Systems製のNASなどが標的になっている
bash の脆弱性 "Shell Shock" のめっちゃ細かい話 (CVE-2014-6271) - もろず blog
※(2014/10/1 追記) 脆弱性の番号を誤って CVE-2014-6721 と表記してしまっていました 正しくは "CVE-2014-6271" です 失礼致しました ※(2014/10/7 追記) 2014/10/7 14:00時点で Shell Shock への修正パッチは6個 公開されています 既に対応済みのシステムでもパッチの漏れがないか注意してください シェルに脆弱性が見つかったらしいです このコマンドを実行すると脆弱性があるバージョンかのチェックができるようです $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" 以下のように表示されたらアウトです vulnerable this is a test どうやら、このコマンドが正常に実行できるというのがこの脆弱性の正体らしく、 echo vuln
ファイアウォール内のサーバに対するShellshockを利用した攻撃 - 葉っぱ日記
2014-09-27: 該当サイト上にXSSがなくても攻撃可能であることが id:mayuki さんのコメントで判明しましたので全面的に書き直しました。ファイアウォール内であっても攻撃者はファイアウォール内のShellshock攻撃が通用するCGIのURLがわかっているだけで攻撃可能ですので早急に対応が必要です！会社のブログにも書いてますが、ファイアウォール内に置いてあるサーバで攻撃者が直接アクセスできないからといってbashの更新を怠っていると、条件によっては攻撃が可能となります。 条件としては、 そのサーバにはシェルを経由して外部コマンドを起動するCGI等が動いている(通常のShellshockの攻撃と同条件) 攻撃者がそのURLを事前に知っている(あるいは推測可能) となります。 攻撃者は、ユーザーを罠URLへ誘導し、以下のようなJavaScriptを罠ページ上で動かし、攻撃対象のW
ウェブアプリにおける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
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
OS XのBashで脆弱性CVE-2014-6271を修正する方法。
Bashの脆弱性CVE-2014-6271をOS X で修正する方法です。詳細は以下から。 昨日明らかになったBashの脆弱性「環境変数に仕込まれたコードを実行してしまうBASHの脆弱性」は既にUbuntuなどでは修正されていますが、OS X ではまだ”command line tools“にアップデートがかからないので、self updateする方法をまとめました。 チェック方法 ターミナル.appを起動して以下の一行を実行 env x='() { :;}; echo vulnerable' bash -c "echo hello" この状態で vulnerable hello と脆弱”vulnerable”と出れば脆弱性が存在します。 HomebrewやMacPorts HomebrewやMacPortsを使用している場合、既にアップデートされているのでそちらをお使い下さい。Homeb
BASHの脆弱性でCGIスクリプトにアレさせてみました
環境変数に仕込まれたコードを実行してしまうBASHの脆弱性が CGIスクリプトに影響を与えるか試してみたら結果は悲惨な感じに Tweet 2014年9月25日 嶋田大貴 この記事は2014年のものです 朝から Bash specially-crafted environment variables code injection attack なるもので騒ぎになっていたので、さっそく手元の Apacheで試してみました。 /hoge.cgiというURIで実行されるように、一行のメッセージを出力するだけの CGIスクリプトを設置します。いっけん、なんの入力もクライアント側から受け付けていないため危険のありようもなく見えます。 #!/bin/sh echo "Content-type: text/plain" echo echo "Hi! I'm an ordinary CGI script w
Bash specially-crafted environment variables code injection attack
This article was originally published on the Red Hat Customer Portal. The information may no longer be current. Update 2014-09-30 19:30 UTC Questions have arisen around whether Red Hat products are vulnerable to CVE-2014-6277 and CVE-2014-6278. We have determined that RHSA-2014:1306, RHSA-2014:1311, and RHSA-2014:1312 successfully mitigate the vulnerability and no additional actions need to be ta
シェルスクリプトのデバッグ | UNIX & Linux コマンド・シェルスクリプト リファレンス
シェルスクリプトのデバッグ シェルスクリプトをデバッグするには プログラムにバグはつきものであり、それはシェルスクリプトも例外ではない。bash にはシェルスクリプトのデバッグに非常に有効なオプションが用意されているので、「Syntax Error」で実行できない場合や、変数にどんな値が設定されているのか確認したい場合は、それらオプションを指定した上で実行することで、簡単にデバッグを行うことができる。 「-x」オプションを使用する -x オプションは、シェルスクリプト内で実際に実行されたコマンドを表示するオプションである。変数が使用されている場合は、その変数の値が展開された状態で表示される。 → bash に -x オプションを指定し、引数にデバッグするシェルスクリプトを指定する。 -x オプションでシェルスクリプトを実行すると、echo コマンドなどの出力に加えて、スクリプト内で実際に実
Pash(cross platform PowerShell)
PowerShell open source reimplementation for "others" (Mac, Linux, Solaris, etc...) and Windows (including Windows Mobile and Windows CE) About the name Pash = Posh (PowerShell) + bash(one of the Unix shells) Goals The main goal is to provide a rich shell environment for other operating systems as well as to provide a hostable scripting engine for rich applications. The user experience should be se
/bin/sh と /bin/bash の違い - 双六工場日誌
みなさん、shebang書いてますか！ Shebangというのは、スクリプトの最初の一行目に書く、「#!/bin/sh」とか「#!/usr/bin/perl」とかそういうあれです。詳しくはWikipediaさん（シバン (Unix)）に聞いてくださいまし。 Twitter見てると、「そもそもこれにshebangなんて名前がついてるの知らなかったよ」という発言も見る不憫な子ではあるのですが、そこに何が書いてあるかで実は動作が違うよってのが今日の本題です。それで、はまっていたのを最近見て、まああまりここで引っかかる人はいないと思いつつ、この点を書いた情報を見ないのでまとめてみました。*1 今日取り上げるのは、bashがデフォルト設定になっているLinuxでの「#!/bin/sh」と「#!/bin/bash」のお話。確認はCentOS5, 6で行なっています。 さて、上記の環境の場合、「/bin
bashによるシェルスクリプトの小技(2) - shibainu55日記
前回(bashによるシェルスクリプトの小技(1))に引き続き、シェルによって自動的に値が設定される特殊な変数について紹介する。特殊な変数を参照することにより、様々な情報を取得することができる(ただし、これらの変数には自分で任意の値を設定することはできない)。 さて、まずは特殊変数を一覧でまとめてみる。お馴染みのものが多いが、最後の2つ(特に最後のPIPESTATUS)についてはきっと今まで知らなかった人もいるんじゃないだろうか。シェルの中でパイプすると途中のコマンドのリターンコード、拾えないとか思っていませんか？今回のポイントとしては、「1. PIPESTATUS変数について」と「2. 特殊変数 $@と$*の違いについて」の2点を主に説明する。 特殊変数一覧表 変数名 自動的に設定される値 $? 直前に実行されたコマンドの終了ステータスが設定される変数。正常終了の場合は「0」、異常終了の場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
