てきとうなメモ

本の感想とか技術メモとか

初詣

こんなまとめを読んだ

togetter.com

一方で元文献の著者の平山昇は以下のように指摘している。

【「初詣」の歴史に関するメディア・ネット上の誤りについて】

「『初詣』は鉄道会社（京急）の営業活動によって誕生したもの」という言説が一部のテレビ番組やインターネットなどで拡散しておりますが、これは私の研究を紹介した過去のメディア報道をせっかちに誤解したもので、端的に誤りです。川崎大師が明治時代に「初詣」の発祥の地となったのは事実ですが、それは京浜電鉄（現在の京急）が誕生するよりも前のことでした。「初詣」発祥の経緯については拙著『鉄道が変えた社寺参詣』にて説明しております。

で、以下のsynodosの記事や著書の「鉄道が変えた社寺参詣」を少し読んでみた。

synodos.jp

現在の初詣の参詣方式は明治20年ごろに誕生したが、ここでいう初詣とは「いつ」「どこに」を指定しない、正月ごろにどこかの寺社に参詣する方式のことである。 これ以前にも元日に参拝することはあったが氏神へのお参りであったり恵方詣(その年の恵方にある寺社に参詣する)であり、それ以外の寺社に参拝するのは珍しいとみなされていた。交通手段が限られていた時代では遠くの寺社に参詣するのが難しかったが、川崎大師が列車でアクセスできるようになり、明治20年代以降、恵方詣のような縁起よりも行楽を重視する参詣客が増えることにより、元日に参詣する方式が定着してきた。

ということのようだ。

ので、鉄道会社が営業活動によって初詣という参詣方式を意図的に生み出したのではなく、初詣が流行ってきたので鉄道会社の営業が激しくなったというのが正しく、因果が逆であるということだろう。

パスワードポリシーとRobert MorrisとKen Tompson

Security

yamdas.hatenablog.com

という記事を見た。

この論文が犯した過ちは二つがあり、一つ目は複数の文字種（小文字、大文字、数字、記号）を含めることがパスワードの安全性を高めるというパスワードの複雑化の推奨で、現実には「p@ssword」や「Password1」といった推測しやすいパターンはセキュリティ向上にはつながらなかった。

二つ目は、パスワードをハッシュ化して保存する方法を提案したことで、結果的にこれがが研究者によるパスワードの実態調査を著しく困難にしてしまい、結果として、パスワードに関する知見の蓄積が停滞しまった。

ということなので、ほんとかなと思って元記事などを辿ってみる。

元のStuart Schechterの記事はこちら

1つ目のパスワードの文字種の複雑化については以下のように記載している。

First, was Morris and Thompson’s confidence that their solution, a password policy, would fix the underlying problem of weak passwords. They incorrectly assumed that if they prevented the specific categories of weakness that they had noted, that the result would be something strong. After implementing a requirement that password have multiple characters sets or more total characters, they wrote:

These improvements make it exceedingly difficult to find any individual password. The user is warned of the risks and if he cooperates, he is very safe indeed.

まず、Stuartの記事ではtotal charactersと文字種だけでなく文字数についても触れている。さらに元論文を辿るとthese improvementsは以下を指している。

The password entry program was modified so as to urge the user to use more obscure passwords. If the user enters an alphabetic password (all upper-case or all lower-case) shorter than six characters, or a password from a larger character set shorter than five characters, then the program asks him to enter a longer password. This further reduces the efficacy of key search.

短いパスワードが入力されたら文字数を長くするように依頼するようなプログラムを書けという話である。現行のNIST SP 800-63が推奨しているパスワードは8文字以上にしろというのと同じ方向性かと思われる。

ただし、論文全体として文字数が多いか文字種を多くするのが良いように書かれているのも確かである。しかし、基本的に文字種やパスワードの長さによって総当たり攻撃に時間がかかるという話をしており、それ自体は事実である。ただ、文字種を強制することで利便性が悪くなることや覚えられないというデメリットに対してそれを上回る効果があるのかという問題があり、NIST SP 800-63では否定されている。

2つ目のパスワードのハッシュ化についてだが、まずStuartの記事でもRobertとKenがハッシュ方式を発明したわけではないと指摘しており、UNIXに導入したり、それを推奨したことを問題としているようである。

While Morris and Thompson did not invent password hashing, they implemented it into Unix, strongly recommended it, and their paper would be the one most cited to support the necessity of password hashing.

ただし、論文の中で提案しているのは、ソルトを付けて総当たり攻撃に対する耐性をつけるべきという話であり、この論文自体がパスワードのハッシュ化自体と関係性が強いかは疑問がある。

ハッシュ化しないのならばどう保存するのかという点については、Stuartは公開鍵方式で暗号化する方法を提案しているようだ。

With RSA, passwords could be hashed with a function that was one-way without the private key, and the private key stored on a system detached from any network and safely behind locks, guards, and whatever other physical security measures one might dream of. When scientists needed to test if password policies were working, they could take the file with the numeric hashes into the locked room with the key, analyze them, and leave with a new set of rules to try. Alas, to my knowledge, nobody has ever used this approach, because after Morris and Thompson’s paper storing passwords in any form that can be reversed became taboo.

1案としてはありかもしれないが、一方向性を持たず開発者がユーザのパスワードを見えてしまうのは問題だろう。パスワードの利用状況を研究できるメリットと、パスワードを開発者や研究者に見られてしまうかもしれないデメリットを比較すると、一般の人はデメリットの方を大きく評価しそうである。

Windowsのipv6によるRCE脆弱性(CVE-2024-38063)

Security

Windows TCP/IP Remote Code Execution Vulnerability CVE-2024-38063

ipv6で特殊なパケットを送ることで任意のコードを実行できるとのこと。パッチは既に出ているので、windows updateをかければ良い。

発見者は詳細を公開する予定がなく、MSもPoCやexploitは現状ないという判断だが、クラッシュさせるPoCを実行することができたと言っている人もおり、そのうちマルウェアに利用される可能性も否定できない。

パッチを当てられない場合は、ipv6を無効にすることで対応可能。ただし後述するように推奨されない。

ipv6を無効にするためには、こちらを参考に以下のようにレジストリ値を追加する。

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0xff /f

ネットワークのプロパティのGUIでのIPv6無効化はサポートされておらず、このレジストリ値と同期しないようである。

Using the network properties GUI to disable IPv6 is not supported

This registry value doesn't affect the state of the following check box. Even if the registry key is set to disable IPv6, the check box in the Networking tab for each interface can be selected. This is an expected behavior.

さらに、同じリンク先にあるように、IPv6を無効化すること自体推奨していない。

Internet Protocol version 6 (IPv6) is a mandatory part of Windows Vista and Windows Server 2008 and newer versions. We do not recommend that you disable IPv6 or its components. If you do, some Windows components may not function.

具体的なipv6無効化による副作用については、Referenceの部分に記載がある。

For more information about the related issues, see the articles below:

  • Example 1: On Domain Controllers, you might run into where LDAP over UDP 389 will stop working. See How to use Portqry to troubleshoot Active Directory connectivity issues
  • Example 2: Exchange Server 2010, you might run into problems where Exchange will stop working. See Arguments against disabling IPv6 and Disabling IPv6 And Exchange – Going All The Way.
  • Example 3: Failover Clusters See What is a Microsoft Failover Cluster Virtual Adapter anyway? and Failover Clustering and IPv6 in Windows Server 2012 R2.

WindowsのFAT32の32GB制限

Windows

以下の記事を読んだ。

Windows 11でFAT32のサイズが最大2TBまで拡大。謎の制約が30年経て解除されたが・・・

ちなみに、FAT32に対して32GBの制限が設けられている理由はWindows 95開発時にフォーマット機能とGUIを開発したDavid Plummer氏が設定した仮の値であり、技術的な制約により設定された値でもないとのことです。これがなぜ30年に渡り踏襲されてしまっていたのかは不明ですが、ついにFAT32に設けられていたこの謎の縛りが30年の時を経て解除されるというちょっとした歴史的な瞬間に立ち会えることになりそうです。

で、何で32GBの制限にしたのだろうかと思って調べてみると、Dave Plummer氏の動画に辿り着いた。

www.youtube.com

動画によると、

  • FAT32はクラスタ数が最大で4M程度という制限があり、ディスクサイズを増やすと、1クラスタのサイズが大きくなる
  • ファイルはクラスタ単位で管理されるので、1クラスタのサイズが増えるとスペースの無駄になる。よってあまり大きなサイズにしたくない
  • 当時テストに使ったメモリカードが16MBで、手に入れることのできた最大サイズだった。これを1000倍して、さらに2倍にすれば、NT 4.0の生存期間中は十分だろうと考えた。

とのこと。

あと、あくまでWindows Shell(GUI)のフォーマット機能の話なので、32GB以上をフォーマットしたい場合は、コマンドラインか3rd partyのツールを使えと言っているので、現状でもformatコマンドで32GB以上フォーマットできるように聞こえる。

となると以下の今回のアップデートが何を指すのかよくわからなくなるが。。。

Announcing Windows 11 Insider Preview Build 27686 (Canary Channel) | Windows Insider Blog

When formatting disks from the command line using the format command, we’ve increased the FAT32 size limit from 32GB to 2TB.

HertzBleed Attack

Security

Hertzbleed Attack

CPUの脆弱性で大きな話かなと思って論文少し読んでみた。が、Q&Aに書かれている通り、すぐに心配すべきものではないという感想。

Should I be worried?

If you are an ordinary user and not a cryptography engineer, probably not: you don’t need to apply a patch or change any configurations right now. If you are a cryptography engineer, read on. Also, if you are running a SIKE decapsulation server, make sure to deploy the mitigation described below.

どんな脆弱性なのか

IntelやAMDの最近のCPUには消費電力が高いとCPUの周波数を減らし、消費電力が低いと周波数を増やすという機能がある。この機能によって、秘密データに依存してある処理の消費電力が変化する場合、周波数も変化するため、処理時間が変化する。この処理時間の変化を観測することによって秘密データを推測することができるかもという脆弱性。

AMDはCVE-2022-23823、IntelはCVE-2022-24436として採番されている。

この攻撃方法のメリット

電力消費の変化から秘密データを推測するという手法はこれまでもあった。しかし、攻撃対象に物理的なアクセスが必要だったり、CPUの電力消費量取得インターフェースにアクセスするために権限が必要だったりして、攻撃することが難しかった。しかし、今回の攻撃方法は処理時間を計測するので、リモートから攻撃できる可能性がある。

また、処理時間の変化から秘密データを推測するという手法(タイミング攻撃)はこれまでもあったが、プログラミングで処理速度を一定にするという対策方法があった。ただし、処理速度を一定にするとは、その処理のクロックサイクル数を一定にすることを指していた。

HertzBleed Attackでは、クロックサイクル数が一定でも電力消費の変化により周波数が変化する。そして、処理時間はクロックサイクル数/周波数で計算されるので、クロックサイクル数が固定でも処理時間は変化する。よってクロックサイクル数一定の処理による対策をバイパスすることができる。

論文ではどのような秘密データを解読できたのか

論文ではSIKEのKEMのdecapsulation処理における秘密鍵を解読している。

実装としてはCloudflareのCIRCL(Cloudflare’s Interop- erable Reusable Cryptographic Library)やMicrosoftのPQCrypto-SIDHを用いている。

decapsulation処理をするHTTPサーバ(CIRCL)、TCPサーバ(PQCrypto-SIDH)を攻撃対象として用意して、リモートからタイミング攻撃を仕掛けることで、36時間(CIRCL)、89時間(PQCrypto-SIDH)で解読している。

SIKEって何？

よく知らないが、Supersingular Isogenyを用いたkey encapsulation suiteとのこと。NISTの耐量子暗号のコンペティションに残っているようだ。

KEMって何？

非対称鍵暗号(公開鍵暗号)は対称鍵暗号と比べて一般的に処理が遅いので、最初に非対称鍵暗号を用いて対称鍵暗号のセッション鍵を共有して、実際の通信はそのセッション鍵で暗号化することが多い。KEM(Key Encapsulation Mechanism)はその非対称鍵暗号で対称鍵暗号のセッション鍵を送る仕組み。

SIKEに対してどのように電力消費の差を生み出して、攻撃することができるのか？

まず、CPUの特性として、計算時のハミング距離(ビットが0→1や1→0に変化した数)やハミング重み(ビットが1の数)が大きいほど電力消費が大きいというのがある。

SIKEへの攻撃では、このうちハミング重みの方を用いている。

SIKEのdecapsulation処理では、秘密鍵のi番目のビットとi-1番目のビットが異なる場合、計算結果が途中からずっと0になる、というような特殊な暗号文を入力することができる。そうするとハミング重みが小さくなるため、消費電力が下がり、周波数が上がり、処理時間が速くなる。この処理時間の変化を用いて秘密鍵を1ビットずつ推測していくことで、秘密鍵の解読に成功している。 (だいぶ省略した説明)

SIKE以外は攻撃できるか？

公式サイトには以下のように書かれている。

Is my constant-time cryptographic library affected?

Affected? Likely yes. Vulnerable? Maybe.

Your constant-time cryptographic library might be vulnerable if is susceptible to secret-dependent power leakage, and this leakage extends to enough operations to induce secret-dependent changes in CPU frequency. Future work is needed to systematically study what cryptosystems can be exploited via the new Hertzbleed side channel.

個人的にも以下のような条件が必要だと思うので、個々の暗号において、この手法を用いて攻撃できたという話が出てくるまでは、何とも言えない気がする。

  • 秘密データに依存して消費電力が変化しないといけない
  • 消費電力の変化→周波数の変化→処理時間の変化が判別できるほど大きくなければならない
  • 処理時間が変化として判別できる単位のインターフェースを外部公開していないといけない(SIKEの例で言うと、decapsulation以外の処理を含めた処理を公開しているのであれば、decapsulation以外の処理の電力消費によってdecapsulationの電力消費の情報が隠れてしまう可能性がある)

log4j2のlookupの変数展開シンタックス

Log4j Security

変数展開シンタックス

CVE-2021-44228の件でLookupにおける変数展開をどうしているのか気になったので、StrSubstitutor.substituteの辺りを読んでみた。

${...}となっている部分のシンタックスは以下のようになっている。

${varName}
${varName:-varDefaultValue}
${varName:\-comment:-varDefaultValue}

varNameは変数名。commentは無視される。varDefaultValueはvarNameをlookupした結果がnullだった場合の値である。

varDefaultValueが設定されていない場合、変数展開はされず、そのままの文字列のままになる。

例えば、

${::-j}

は、「:」がvarName、jがvarDefaultValueになり、:はlookupできないため、デフォルト値のjに展開される。

varNameは以下のようにprefixとnameに分かれる。

prefix:name

prefixはどのLookupを使うのかのkeyになる。jndiだったらJndiLookup、lowerだったらLowerLookupのコードが実行される。InterpolatorでどのprefixがどのLookupを使うかを管理している。

さらに、この変数展開は入れ子と再帰をサポートしている。

入れ子は以下のようなものである。

${${x}}

${x} = y, ${y} = z であれば、これはzに展開される。

再帰は次のようなものである。

${x} = ${y}, ${y} = zであれば

${x}

はzに展開される。

CVE-2021-45105

再帰に関してはv2.14.1の時点でもStrSubstitutor.checkCyclicSubstitutionで無限に再帰するのをチェックしている。再帰呼び出しをするときに変数名を保持し、同名の変数名の展開になった場合に例外を出力している。

しかし、入れ子の処理における再帰呼び出しの場合は変数名を保持して再帰呼び出しをしていない。そのため、CVE-2021-45105の脆弱性が発生していた。

${x} = ${${x}}としておくと、無限に変数展開されていく。同名の変数を利用しているのだが、入れ子の処理の再帰呼び出しでは前回展開した変数名を保持していない。そのため、無限に再帰呼び出しが実行され、スタックが枯渇し、DoS攻撃が可能となっていた。

この脆弱性はv2.17.0で解消している。

metaタグによるSet-Cookie

Security HTML

metaタグでSet-Cookieできる(できた)ことを知らなかった。

<meta http-equiv="Set-Cookie" content="sessionid=xxxxx">

metaタグをインジェクト可能な脆弱性が存在すると攻撃者がcookieを設定させることができてしまう。

ただ、現行のHTML Living Standardによると

HTML Standard

Set-Cookie state (http-equiv="set-cookie") This pragma is non-conforming and has no effect.

User agents are required to ignore this pragma.

となっているのでユーザエージェントは無視しないといけない。

試してみると以下のようにIE以外は無視しているようだ。

ブラウザ バージョン Set-Cookieできる?
IE 11 o
Edge 97 x
Chrome 96 x
FireFox 95 x
Safari 15 x