Notices by h12o (h12o@mastodon.tokyo), page 2

@hyoyoshikawa ご確認ありがとうございます。

Tenableの文章で、ピリオドがあって然るべきところがないように見受けられる箇所があったので、そこが原因かもしれません。

@hyoyoshikawa すみませんが質問です。diffとリンク先からは「問題は、Mastodon内のLDAP認証設定において、認証リクエストの起源を適切に検証していない点にあります。」とは読み取れなかったのですが、どの辺りを訳されたか知りたいと思っています。

脆弱性の詳細は私自身把握していない（把握していたとしても公式情報以上は書かない）のですが、MastodonのLDAP連携機能に脆弱性があるのだとすると、攻撃条件が複雑になってCVSSがそこまでは上がらないのでは?と思っているとともに、大多数のサーバーは影響を受けないとも考えていて、私の頭の中で整理がついていません……

Mastodonに「リモートユーザーのなりすましと乗っ取り」ができる脆弱性だそうで、2月15日に詳細が追って通知されるため、2月14日までに対応をすることをお勧めします。

（以下はh12oによる機械翻訳ベースの翻訳）

まとめ

すべてのMastodonでオリジンの検証が不十分なため、攻撃者はあらゆるリモートアカウントになりすまして乗っ取ることができます。

3.5.17 より前のすべてのMastodonバージョンに脆弱性があるほか、4.0.13より前の4.0.xバージョン、4.1.13より前の4.1.xバージョン、4.2.5より前の4.2.xバージョンも脆弱です。

詳細

追って通知します。このアドバイザリは、管理者の更新に要する時間を考慮して、2024年2月15日により詳細な情報が追加されます。これは、多少なりとも詳細があることによって、攻撃が非常に容易になると想定されるためです。

https://github.com/mastodon/mastodon/security/advisories/GHSA-3fjr-858r-92rw

A: セキュリティを専門されない方であることを前提とします。
ファーストステップとしては、非エンジニアであれば、国家資格では「情報セキュリティマネジメント試験」、民間資格では「個人情報保護士」、そしてその問題集があるといいと思います。
エンジニアであれば、加えて徳丸本・結城本と徳丸試験をお勧めします。
#FediQB
https://fediqb.y-zu.org/questionbox/@h12o@mastodon.tokyo

>>
修正された脆弱性の内、パスワードリセット機能における脆弱性（CVE-2023-7028）が悪用された場合、任意のユーザーアカウントのパスワードが第三者によりリセットされ、多要素認証を有効にしていない環境ではアカウントの乗っ取りに繋がる可能性があります。なお、同脆弱性の実証コード（PoC）と見られる情報が既に公開されています。

影響を受けるバージョンを利用している場合は、GitLabが提供する情報を参考に、対策や調査を実施いただくことを推奨します。脆弱性を悪用する攻撃の被害を受けた可能性があるかどうかログを調査する方法がGitLabから公開されています。
<<
https://www.jpcert.or.jp/newsflash/2024011601.html

基本的にはまず自分だけでもいいので多要素認証をとにかく有効にしたうえで、作業時間を早めにとってGithubのバージョンアップをすることかな、と思った。

@nelsoncoffeeroaster ニッカニッカ笑っている姿が目に浮かびます（駄）。

みなさま、よいお年を。

@monaco_koukoku @yamako 歯の話ですね、こちらもどうぞ。こちらは残念ながら一言入っちゃってますが。

宗教の教義は、聖典を読み解いて積み上げていくもので、そう簡単に出来上がるものではない。もしその宗教も教義が簡単に定まってしまうようなものだったら、「私は神を作っています」と言っていることになってしまう。それは神を畏れ、神の言葉に従うという態度とは矛盾している。

だからこそいまになって教皇が同性パートナーの祝福を容認することを明文化したのだろう。

私たちは何度も神の言葉を聞き間違います、お赦しください（「お許しください」ではない）、どうか神の言葉を教えてください、と言い続けているのがキリスト教という宗教で、特にカトリックは、2000年間、教義を「追求」している、と僕は理解している。

それともうひとつ、キリスト教では自然や人間社会もまた神の啓示なので、無視していい存在ではない。人間社会に迎合しているように見えるのも迎合ではなくて、そこに神の啓示を見ようとして自分の考えを改めていくという過程だ。

僕は、テキストコミュニケーションで「w」をめったに使わない。

>>
以上の歴史的経緯から、「w」が意味するところは基本的には「笑」であるが、そのニュアンスについては文脈に大いに依存することがわかると思う。この場合の文脈というのは、読み手側から見ると、行間に隠された(本当に隠されているかどうかは別)文まで含んでしまうものであるため、明確に嘲笑で無い、と言い切ることの出来る場合を除いて、常に嘲笑と受け取られる可能性があると心得ておくべきである。
<<
https://nov1975.hatenablog.com/entry/20070625/p4

というわけで、文脈やシチュエーション次第では嘲笑ととらえられやすいから。

そして、正直なところ驚いたのだけど、嘲笑ととらえられやすいリスクを把握しておらずに場を和ませようと「w」を使う人がいる、ということを今日知った。

>>
利用者に今すぐ行動してもらえるのでしたら、自分が使う絵文字リアクションに気をつけてください。
<<
https://note.com/kmycode/n/n9a2ecc2cf944

「今年4月26日に実際に起きた一つの事件」の存在そのものを僕はたったいま知ったし、詮索する気はない。というわけで、この文書が怪文書かどうかはさておくとして、「絵文字リアクションが中傷に利用できる危うさ」の認識は大切だと思う。そして、オリジナルのMastodonは、誹謗中傷などにつながるという理由で引用機能もリジェクトしているくらいなので、Mastodon gGmbHでも「絵文字リアクションが中傷に利用できる危うさ」も認識しているのではないかと思っている。もう少し探せばそれを示すものがあるのかもしれない。

化石賞そのものについてはさて置くのだけど、この箇所に目が留まった。
>>
何が足りないかを明らかにするには、いまできていることをちゃんと評価することも大事
<<
https://comemo.nikkei.com/n/n49f0a4eb9ae8

自分も最近になってようやく気付いたのだけど、自分で振り返るにせよ人に伝えるにせよ、できていることとその評価をしっかりと合意しないと、できていないことに立ち向かえないのではないかと思っている。行き過ぎた謙遜は傲慢と言う人がいるが、「何でもできる」と「何もできない」は、「できていないことに立ち向かう」という人間の務めを放棄している点では、同じくらいの傲慢なのかもしれない。

セツゾクスタジオのMastodon
#FediLUG
https://setsuzokustudio.com/news-entries/2023/start-mastodon-server.html

僕は知的好奇心の赴くままに動いてしまう癖があるというか、手段のためなら目的を選ばないタイプだと自覚しているので、新規事業とかやりとげるとかそういうのが苦手っぽいなと思いつつあるのだけど、ふと思いついて、技術同人誌を自分で刊行してみるのはどうだろうと考えた。

儲けが出るかどうかとかそういうのは別にして、「事業」を「遂行」することの「真似事」として、技術同人誌を企画、刊行してみるというのは、CxOの気持ちを知る上でいいことなのではないかということ。

もろびとこぞりて恵方に向かってシュトーレンを丸かぶりですか（混ぜるな）

>>
嫌いなのはそのまま率直に嫌いで良いので、自分で選ばないなり、避けるなりすればいいだけで、嫌いだから攻撃するなんてことはしなくていいんです。
<<
https://fujii-yuji.net/2023/12/09/134002

本当にこれなんだけど、近現代でようやく成立した「人権」という概念は実はこれ。早いところこの辺を理解しないと、「人権は人類には早過ぎたんだ」という笑えない話になってしまうことを、僕は心配している。

>>
俺たちが夢見たいんたーねっつも
あきれるほどおめでたい理想の世界だったはず

なんだよね

アドテクが「刺激的な広告を沢山の人に見せる」なんて物量作戦に負けるなんて結末、そんないんたーねっつでいいのかよって思うんだけどなあ。
<<
ホントこれで。そろそろ僕はいんたーねっつに悲観し始めている頃なんだけど、いんたーねっつの松岡修造（※）ことフジイユウジ @fujii_yuji さんはちゃんとポエムを書けるほど希望を持っているんだな、そこがすごいなと思う。

※名付けたのはたぶん僕

いまからでも間に合うかね?

https://fujii-yuji.net/2023/12/10/230716

@mamemomonga そして、こういう実装は割とありがちです。理由は、認可制御マトリックスを正しく作ってテストすることが面倒だからで、「実装が億劫になる。なので後回しになっていた」のではないかな、という想像自体は自然なことだと思います。

@mamemomonga 「APIの認証がかかってなかった」と言い切れないだけで、実は本当にAPIの認証がかかってなかったことも考えられはしますが、一方で、「（ログインしているユーザー以外のデータであっても）全ての（ユーザーのデータを引っ張ってこれる）クエリに答えるようになっていた」ことも考えられます。

たとえば`/api/v1/:uid/matchingapplist?format=json`というAPI（`:uid`は利用者のID）でインストールされているマッチングアプリの一覧が取得できるとします。

まめもさんがuid=10000、h12oがuid=10001だとして、まめもさんがまめもさんとして認証された状態で、それに紐づいたBearerトークンを使って、`/api/v1/10001/matchingapplist?format=json`にクエリを出して、h12oのmatchingapplistが取れてしまったら、これは認可制御の不備ということになります。

@mamemomonga 認可制御の不備であれば、Bearerトークンそのものを解析する必要はありません。APIリクエストに正しいBearerトークンを載せればいいだけで、それは攻撃者が自身の認証を通せばいいからです。