Tag: bug

EULA 不能禁止使用者 decompile 修 bug

Hacker News Daily 上翻到的，歐洲法院認為 EULA 不能禁止使用者 decompile 修 bug：「EU court rules no EULA can forbid decompilation, if you want to fix a bug (europa.eu)」，官方的英文版文件在這邊可以翻到，不過原始判決是法文：

* Language of the case: French.

這是 Top System SA 與比利時政府打的訴訟，法院認為修 bug 而需要 decompile 這件事情是合法的，即使考慮到 Article 6 的規範：

In the light of the foregoing considerations, the answer to the first question referred is that Article 5(1) of Directive 91/250 must be interpreted as meaning that the lawful purchaser of a computer program is entitled to decompile all or part of that program in order to correct errors affecting its operation, including where the correction consists in disabling a function that is affecting the proper operation of the application of which that program forms a part.

In the light of the foregoing considerations, the answer to the second question referred is that Article 5(1) of Directive 91/250 must be interpreted as meaning that the lawful purchaser of a computer program who wishes to decompile that program in order to correct errors affecting the operation thereof is not required to satisfy the requirements laid down in Article 6 of that directive. However, that purchaser is entitled to carry out such a decompilation only to the extent necessary to effect that correction and in compliance, where appropriate, with the conditions laid down in the contract with the holder of the copyright in that program.

案子看起來應該還有得打？看起來好像不是最終判決...

REQUEST for a preliminary ruling under Article 267 TFEU from the Cour d’appel de Bruxelles (Court of Appeal, Brussels, Belgium), made by decision of 20 December 2019, received at the Court on 14 January 2020[.]

但不管怎樣，算是有些東西出來了... 然後 Hacker News 上面的討論就看到一些很歡樂的例子：

This becomes incredibly interesting in terms of e.g. Denuvo. This anti-piracy middleware has been shown to make games unplayable, and this EU law seems to support removing it.

哭啊怎麼提到該死的 Denuvo XDDD

Shell Script 裡面 [ "x$var" = "xval" ] 的歷史

看到「What exactly was the point of [ “x$var” = “xval” ]?」這篇，在講為什麼不直接寫 [ "$var" = "val" ] 而是會加上 x 而寫成 [ "x$var" = "xval" ]，被稱為 x-hack 的 workaround... (其實已經變成 best practice 了)

最常被拿出來講的是 - 開頭的字串，不過文章作者找到更多奇怪的 bug report，像是 ( 與 ) 之類的問題 XD

雖然作者提到大概在 2010 (或是 2015) 都修完了，但我應該還是會繼續這樣寫 (算是 best practice 了)，可以避免在遇到老系統上遇到問題...

利用 Cloudflare Workers 繞過 Cloudflare 自家的阻擋機制

在 Hacker News 首頁上看到「How to bypass Cloudflare bot protection (jychp.medium.com)」這則，裡面的文章是「How to bypass CloudFlare bot protection ?」這篇，利用 Cloudflare Workers 繞過 Cloudflare 自家的 CAPTCHA 機制。

這個漏洞有先被送給 Cloudflare，但被認為不是問題，所以作者就決定公開：

Several months ago I submitted what appeared to be a security flaw to CloudFalre’s bugbounty program. According to them, this is not a problem, it’s up to you to make up your own mind.

技術上就是透過 Cloudflare Workers 當作 proxy server，只是看起來 Cloudflare 對自家 IP 有特別處理，在設定妥當後，用 Cloudflare Workers 的 IP address 去連 Cloudflare 的站台，幾乎不會觸發 Cloudflare 的阻擋機制。

不過 free tier 還是有限制，主要就是數量：

The first 100,000 requests each day are free and paid plans start at just $5/10 million requests, making Workers as much as ten-times less expensive than other serverless platforms.

作者也有提到這點：

So let’s enjoy the 100 000 request/day for your free Cloudflare account and go scrape the world !

但這是個有趣的方法，加上信用卡盜刷之類的方式，這整包看起來就很有威力...

打穿蘋果的企業網路

上個禮拜丟出來很轟動的一篇「side project」，三個月不斷的打穿蘋果的企業網路：「We Hacked Apple for 3 Months: Here’s What We Found」，對應的 Hacker News 討論可以在「We Hacked Apple for 3 Months (samcurry.net)」這邊看到。

在最後面有提到這本來是打好玩的，但後來就投入愈來愈多時間進去：

This was originally meant to be a side project that we'd work on every once in a while, but with all of the extra free time with the pandemic we each ended up putting a few hundred hours into it.

這是五個人通力合作打了三個月出來的成果，依照他們的回報數字，共打出了 55 個「洞」，考慮到週休的情況，幾乎是天天打洞出來玩：

There were a total of 55 vulnerabilities discovered with 11 critical severity, 29 high severity, 13 medium severity, and 2 low severity reports. These severities were assessed by us for summarization purposes and are dependent on a mix of CVSS and our understanding of the business related impact.

文章裡沒有對每個安裝漏洞都描述，但有針對一些比較「有趣」的漏洞說明，雖然看了以後知道是怎麼一回事，但對這些手法沒這麼熟，你叫我打我還是不會打啊 XDDD 反而是當作表演藝術來看...

Mass Effect 的 3D 場景黑塊問題一路追到 Intel/AMD 的 SSE2 指令集...

Mass Effect 是個 2007 在 Xbox 上推出的遊戲，並且在 2008 推出 Windows 版，這個遊戲在 2011 年 AMD 推出的 CPU 上 (Bulldozer)，某些場景會產生人物黑塊的 bug，社群有些猜測但一直都沒被證實，作者一路追出不少問題，並且給了一個還算乾淨的 workaround：「Fixing Mass Effect black blobs on modern AMD CPUs」，另外在 Hacker News 上有很精彩的討論：「Fixing Mass Effect black blobs on modern AMD CPUs (cookieplmonster.github.io)」。

這篇主要是看趣味的，裡面的狀況有點複雜。

社群有一些 workaround 可以避開這個問題，作者後來是從關閉 PSGP (Processor Specific Graphics Pipeline) 的方法找問題，然後發現在計算時會產生出 NaN 的問題，所以導致貼出來的圖就變成黑塊了...

一路追下去，發現遊戲本身好像沒什麼大問題，但跟 Direct3D 裡面的 D3DXMatrixInverse 有關，會依照 CPU 的支援度決定怎麼跑：

  • Disabling PSGP makes both Intel and AMD take a regular x86 code path.
  • Intel CPUs always take an intelsse2 code path.
  • AMD CPUs supporting 3DNow! take a amd_mmx_3dnow or amd3dnow_amdmmx code path, while CPUs without 3DNow take an intelsse2 code path.

會有這些邏輯是因為 AMD 在 2010 後決定放生 3DNow!，所以會需要這樣判斷。

接著寫了一隻小程式測試，用 memcmp() 判斷是不是一樣，結果發現 AMD 的 SSE2 跑出來的程式不被遊戲接受：(不一樣是正常的，因為這些指令本來就沒有要求完全正確，是可以接受誤差的)

接著就是翻資料，可以知道 XMMatrixInverse 算是接班人：

I figured that since we were to replace that matrix function anyway, I could try replacing it with XMMatrixInverse being a “modern” replacement for D3DXMatrixInverse. XMMatrixInverse also uses SSE2 instructions so it should be equally optimal to the D3DX function, but I was nearly sure it would break the same way.

所以就弄個一個 DLL，把本來呼叫 D3DXMatrixInverse 的部份用 XMMatrixInverse 改寫換掉：「SilentPatchME/source/D3DXMatrix.cpp」，這個方式算是乾淨的 workaround 掉，保持 API 相容性，以及該有的加速能力 (由 XMMatrixInverse 提供)。

Hacker News 上有討論到 Intel 與 AMD 這些指令在 SSE2 上的誤差值，都是在規格要求的範圍內：

Const-me 14 hours ago [–]

Here’s Intel versus AMD relative error of RCPPS instruction: http://const.me/tmp/vrcpps-errors-chart.png AMD is Ryzen 5 3600, Intel is Core i3 6157U.
Over the complete range of floats, AMD is more precise on average, 0.000078 versus 0.000095 relative error. However, Intel has 0.000300 maximum relative error, AMD 0.000315.

Both are well within the spec. The documentation says “maximum relative error for this approximation is less than 1.5*2^-12”, in human language that would be 3.6621E-4.

Source code that compares them by creating 16GB binary files with the complete range of floats: https://gist.github.com/Const-me/a6d36f70a3a77de00c61cf4f6c17c7ac

至於為什麼會生出 NaN 的原因，沒找出來還是有點可惜，不過這個解法還行，就是「新版的 library 既然沒問題，就大家也不要太計較舊版的問題」的概念...

PostgreSQL 的 SERIALIZABLE 的 bug

這是 Jespen 第一次測試 PostgreSQL，就順利找出可重製的 bug 了：「PostgreSQL 12.3」。

第一個 bug 是 REPEATABLE READ 下的問題，不過因為 SQL-92 定義不夠嚴謹的關係，其實算不算是 bug 有討論的空間，這點作者 Kyle Kingsbury 在文章裡也有提出來：

Whether PostgreSQL’s repeatable-read behavior is correct therefore depends on one’s interpretation of the standard. It is surprising that a database based on snapshot isolation would reject the strict interpretation chosen by the seminal paper on SI, but on reflection, the behavior is defensible.

另外一個就比較沒問題了，是 SERIALIZABLE 下的 bug，在 SQL-92 下對 SERIALIZABLE 的定義是這樣：

The execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable. A serializable execution is defined to be an execution of the operations of concurrently executing SQL-transactions that produces the same effect as some serial execution of those same SQL-transactions. A serial execution is one in which each SQL-transaction executes to completion before the next SQL-transaction begins.

也就是說，在 SERIALIZABLE 下一堆 transaction 的執行結果，你至少可以找到一組排序，使得這些 transaction 的結果是等價的。

而 Jespen 順利找出了一組 transaction (兩個 transaction)，在 SERIALIZABLE 下都成功 (但不應該成功)：

對於這兩個 transaction，不論是上面這條先執行，還是下面這條先執行，都不存在等價的結果，所以不符合 SERIALIZABLE 的要求。

另外也找到一個包括三個 transaction 的情況：

把 transaction 依照執行的結果把 dependency 拉出來，就可以看出來裡面產生了 loop，代表不可能在 SERIALIZABLE 下三個都成功。

在 Jespen 找到這些 bug 後，PostgreSQL 方面也找到軟體內產生 bug 的部份，並且修正了：「Avoid update conflict out serialization anomalies.」，看起來是在 PostgreSQL 引入 Serializable Snapshot Isolation (SSI) 的時候就有這個 bug，所以 9.1 以後的版本都有這個問題...

這次順利打下來，測得很漂亮啊... 翻了一下 Jespen 上的記錄，發現好像還沒測過 MySQL，應該會是後續的目標？

Intel 的 RDRAND 爆炸...

在正妹 wens 的 Facebook 上看到的，Intel 的 RDRAND 因為有安全漏洞 (CrossTalk/SRBDS)，新推出的修正使得 RDRAND 只有原來的 3% 效能：

從危機百科上看，大概是因為這個指令集有 compliance 的要求，所以這個安全性漏洞必須在安全性上修到乾淨，所以使用了暴力鎖硬解，造成效能掉這麼多：

The random number generator is compliant with security and cryptographic standards such as NIST SP 800-90A, FIPS 140-2, and ANSI X9.82.

不過畢竟這個指令不是常常被使用，一般使用者的影響應該是還好：

As explained in the earlier article, mitigating CrossTalk involves locking the entire memory bus before updating the staging buffer and unlocking it after the contents have been cleared. This locking and serialization now involved for those instructions is very brutal on the performance, but thankfully most real-world workloads shouldn't be making too much use of these instructions.

另外這個漏洞早在 2018 九月的時候就通報 Intel 提了，但最後花了超過一年半時間才更新，這算是當初在提 Bug Bounty 制度時可能的缺點，在這次算是比較明顯：

We disclosed an initial PoC (Proof-Of-Concept) showing the leakage of staging buffer content in September 2018, followed by a PoC implementing cross-core RDRAND/RDSEED leakage in July 2019. Following our reports, Intel acknowledged the vulnerabilities, rewarded CrossTalk with the Intel Bug Bounty (Side Channel) Program, and attributed the disclosure to our team with no other independent finders. Intel also requested an embargo until May 2020 (later extended), due to the difficulty of implementing a fix for the cross-core vulnerabilities identified in this paper.

回到原來的 bug，主要還是 Intel 架構上的問題造成大家打得很愉快，現在 Intel 這邊的架構對於資安研究員仍然是個大家熱愛的地方... (因為用的使用者太多)

Let's Encrypt 在檢查 CAA 時出包

Let's Encrypt 發現在檢查 CAA 的程式碼有問題，發了說明：「2020.02.29 CAA Rechecking Bug」，以及預定的處理方式：「Revoking certain certificates on March 4」。

問題是當一個 certificate request 包含了 N 個 domain 時，本來的 CAA 檢查應該要對這 N 個檢查，但程式寫成只會抓一個，然後檢查了 N 次：

The bug: when a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.

2020/02/29 發現的，就程式碼的部屬時間，發現應該從去年 2019/07/25 開始就有這個 bug：

We confirmed the bug at 2020-02-29 03:08 UTC, and halted issuance at 03:10. We deployed a fix at 05:22 UTC and then re-enabled issuance.

Our preliminary investigation suggests the bug was introduced on 2019-07-25. We will conduct a more detailed investigation and provide a postmortem when it is complete.

然後決定要 revoke 這些可能會有問題的 SSL certificate，大約佔現有還有效的 SSL certificate 的 2.6%，大約三百萬筆：

Q: How many certificates are affected?
A: 2.6%. That is 3,048,289 currently-valid certificates are affected, out of ~116 million overall active Let’s Encrypt certificates. Of the affected certificates, about 1 million are duplicates of other affected certificates, in the sense of covering the same set of domain names.

在「Check whether a host's certificate needs replacement」這邊可以偵測線上使用的 SSL certificate 是否受到影響。

另外在「Download affected certificate serials for 2020.02.29 CAA Rechecking Incident」這邊可以抓到所有受到影響，預定要 revoke 的 SSL certificate 的序號。關於取得序號的方式，官方也有提供 CLI 的指令可以操作確認，對於有很多網域名稱需要確認的人可以用這組指令編寫程式判斷：

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial\ Number | tr -d :

照目前的描述，如果申請時只有一個 domain 應該是不會中這個問題，再來是最壞的情況大概會維持三個月 (網站主人沒管他，等到時間到了自動 renew)。

家裡電腦裝 Ubuntu 18.04

上個禮拜四家裡的桌機開不了機，找了一天發現是系統的 SSD 掛掉了，就買了張 M.2 SSD，然後計畫順便把本來的 Ubuntu 16.04 升級到 Ubuntu 18.04，但 Ubuntu 18.04 把預設的界面從 Unity 換成 GNOME (然後披上 Unity 的皮)，加上前陣子系統從 Intel 平台換到 AMD，整個狀況變得超混亂之後，就變成一連串踩地雷的過程...

最一開始是 UEFI + LUKS 的安裝問題，本來想裝到 M.2 SSD 上面，但 Ubuntu 18.04 的 grub-install 就是硬寫到 /dev/sda 不能改：「“Unable to install GRUB in /dev/sda” when installing GRUB」，照著這篇的 workaround 用還是不行，最後放棄，直接生一顆 SATA SSD 接到 SATA Port 1，把 M.2 當作資料碟。

硬體相關的問題：

軟體相關的問題：

  • 目前不支援從 GUI 設定 PPPoE 的網路 (沃槽)，幾種方式裡面我推薦用 pppoeconf 設定會比較好，然後可以改 /etc/ppp/options 加上 IPv6 的設定。
  • 本來想裝 gnome-shell-extension-system-monitor 觀察系統狀態，但會造成系統超級卡，關掉後就變成普通的卡 (後來就找到 Intel I211-AT 的那個問題了)。

現在至少是堪用的程度了，接下來就是不斷的補各種設定...