SUPEE-9767、modmanおよびシンボリックリンク

16

SUPEE-9767でMagentoショップにパッチを適用したいと思います。SUPEE-9767のドキュメントには、パッチを適用する前にSymlinks設定を無効にするように指示されています。

パッチを適用するか、最新リリースにアップグレードする前に、必ずSymlinks設定を無効にしてください。設定が有効な場合、構成ファイルの設定が上書きされ、変更するには直接データベースを変更する必要があります。

しかし、モジュールの管理にはmodmanを使用します。一部のモジュールはテンプレートファイルを使用しているため、Symlinks設定はmodmanのREADMEの提案に従って有効になっています。セキュリティパッチSUPEE-9767-考えられる問題の投稿の1つとして、Symlinks設定を有効のままにしておくのは安全ですか？提案（私は新しいユーザーなのでまだ投稿にコメントできません）

modmanを使用してMagento 1.xモジュールを管理するユーザーは、symlinkを無効にしないでください。これにより、modmanモジュールが無効になります。

Symlinks設定を有効のままにすると、ショップはAPPSEC-1281：symlinksを介したリモートコード実行にさらされませんか？このパッチが修正するセキュリティ上の脅威ですか？

このパッチの後にテンプレートファイルでmodmanを使用する他の方法はありますか？（modmanのREADMEが言及している「Mage / Core / Block / Template.phpのパッチバージョン」オプションは知っていますが、コアファイルへのパッチ適用は危険なようです。）

patches modman supee-9767

— エハンネス
ソース

1

プロジェクトでModmanとComposerを使用しています。長年、MagentoのSymlinksオプションが爆弾と見なされていなかったとは信じられません。突然それは爆弾です！通知や説明なしでこの変更を行うと、多くの人に多くのトラブルが発生します。MagentoでのModmanとComposerの将来については悲しい。

— ADDISON74

1

それはかなりの挑戦です。投資を行う意思がある場合、マージされた（シンボリックリンクなしの）アーティファクトを生成するビルドプロセスを作成することは、本当に良い方法です。

— SwiftOtterでジョセフ

これに関する優れた記事はtomlankhorst.nl/にあります。彼は、Magento 1.9.3.4で導入された「シンボリックリンクが有効になっています」という警告を取り除く方法についても説明しています。

— エハネス

14

この変更に関する説明を次に示します。

最初にPeter O'Callaghanからこの説明を読んでください。これにより、大きな理解が得られます：https：//peterocallaghan.co.2017/appsec-1281-dangerous-symlinks/

また、別の興味深い読み物は、Max Chadwickによるこの投稿ですhttps://maxchadwick.xyz/blog/what-allow-symlinks-actually-does

この変更は、実際にはテンプレートディレクティブを介してアップロード可能なコンテンツ（画像など）を呼び出すことです。

これらは、設定自体に加えて、悪用される既知の方法に対する保護であることに注意してください。

したがって、関連するリスクを理解している場合は、シンボリックリンクを有効のままにしておくことができます。

新規インストールでそれらを有効にする必要がある場合は、次を実行できます。

UPDATE core_config_data SET value = 1 WHERE path = "dev/template/allow_symlink";

— デジタルピアニズムのラファエル
ソース

シンボリックリンクを有効にしておくと、「APPSEC-1281：シンボリックリンクを介したリモートコード実行」からショップをどのように保護できますか？

— エハネス

エクスプロイトにはバックエンドアクセスが必要なため、@ ehannesはバックエンドへのアクセスを保護して開始します。さらに、画像のアップロードには追加のコールバック検証があります。

— デジタルピアニズムのラファエル

3

管理者アクセスを取得すると、Magentoバックエンドインターフェース全体にアクセスできるようになります。アップロード画像スクリプトに見られるこの段階での悪用を気にする人はいますか？その悪意のあるユーザーはすべての製品を削除でき、想像もできないことをすることができます。議論は「真の管理者が多くの点でバックエンドを保護していないためにこのユーザーが管理者権限を取得した場合」で開始する必要があります

— -ADDISON74

1

@ehannesはこのお読みくださいpeterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinksを

— デジタルPianismでラファエル

2

Peter O'Callaghanは次のように書いています。「だから誰かがあなたの管理パネルにアクセスできた場合、悪意のあるincludeを実行してRCEを達成することができます。」これは、この議論の一般的な結論のようです。前に述べたように、悪意のあるユーザーが管理パネルにアクセスできる場合、RCE以外にも心配することがあります。誰かが議論に追加するものを持っている場合は、してください。とにかく、@ RaphaelatDigitalPianismをより明確にしたと思います。この回答を受け入れます。

— -ehannes

6

問題はシンボリックリンクではなく、問題はなどのレベルに到達するパスです../../../../../media/tmp/hahaha.png。これについて間違っている場合は、教えてください。「修正」には「Allow symlinks」というタイトルが付けられ、これを有効にすると、を使用して実装されたチェックが無効になりますrealpath()。私の意見ではちょうど、安全なよりパフォーマンスとシンボリックリンクとまだ互換性があるとされている修正プログラムが使用することstrpos($path, '..')、および/またはことを確認するrealpath()などの特定危険なディレクトリと一致するmediaとはvar。このように実装された場合、構成可能にする必要はなく、常に有効にでき、数千のストアを壊すことはありません。

とにかく、Webサーバーのユーザーはソースコードディレクトリにファイルを書き込むためのアクセス権を持たないようにする必要があります（Magento Connectのように...）。

したがって、シンボリックリンクに対するこの攻撃は誤った方向に向けられており、より良い修正が存在します。実際、1 年以上前に1つ提供しましたが、modman githubのREADMEにもリンクがあります。

— コリンM
ソース

0

コンポーザーファイルの追加でmagento-deploystrategyを設定すると、ファイルはSymlinksではなくベンダーフォルダーからコピーされます。

    "extra":{
        "magento-root-dir":"./",
        "magento-deploystrategy":"copy",
        "magento-force": true
    }

その後、core_config_dataを変更して、dev / template / allow_symlinkの値を0に設定できます。

情報源

— ワークステーションB
ソース

0

このパッチの後にテンプレートファイルでmodmanを使用する他の方法はありますか？

SUPEE-9767の変更はさまざまな方法でオーバーライドできます。以下を参照してください。

SUPEE-9767 V2のインストール後にシンボリックリンクを有効にする方法は？

— sv3n
ソース