[校園] 教你用電子投票 NTUvote102-2 寫 Hello World

看板NTU作者 (js餡鍋)時間10年前 (2014/05/28 23:55), 10年前編輯推噓71(71065)
留言136則, 67人參與, 最新討論串1/1
雖然小魯的專長不是大型網站開發或資安滲透測試, 但是畢竟還是對資訊有一點興趣,在大三以後接觸了不少阿宅小知識, 對於今次的所謂「電子投票」(嗎?) 的許多爭議,潛在水裡看了看 覺得應該可以對該系統本身的設計、程式架構、安全性的眾多問題提出一些意見。 首先是看個影片。寫程式的阿宅總會想套用老梗「 hello world 」在初見的新玩意兒上。 我們可不可以請投票系統 hello world 一下呢? (註: 該漏洞在投票前就已修正) http://vimeo.com/96702478 就如影片當中所顯示的,只要投票者有心,並且他能在短時間內想辦法用 VPN 內網的裝置 (例如投票的平板) 快速輸入大約 170 characteres 的魔法咒語, 就可讓遠端伺服器執行任何你想要的指令。(例如 rm -Rf . 之類的) 這裡只是為了展示概念而簡單地 touch hello-world 一下,不需多做解釋; 總之在影片左上角可以看到 git repository 內容可以成功地被我們投票者修改。 不過 real world attackers 想要做的當然遠遠不止這些, 所有該 process uid 可以做的事情咱們都能做到... 這就要看人們的想像力了。 至於為什麼這個系統會有這樣的問題呢?鄙人認為有數個因素,在此列出幾小點。 1. 撰寫整個網站沒有善加利用已經存在的 Web development frameworks 想要使用 MVC ,但是對 PHP 不是太熟悉的話,就不應該徒手去刻。 自己刻的話,各種安全性議題的 edge case 要考慮全面是很辛苦的。 2. 系統設計看起來有許多邏輯上的問題、怪異之處 舉例來說「身份認證」不應該是隨便想一套算法,套個 MD5 就可以 work 的, 應直接找現有的方案來套用。數學系及資訊系都有人對資訊安全、密碼技術相當了解, 遇到問題時向他們咨詢也是需要的。 舉例來說,像是影片中的攻擊,之所以成立, 應該是因為有一個像這樣的奇怪的判斷條件可以被 bypass with arbitrary code: f( some_constant || user_input_key1 ) === user_input_key2 其中 f 是一個 cryptographically insecure one-way function 這裡只是很簡單地描述而已,實際狀況比較複雜,可以直接參照 code 。 使用者輸入的這個 key1 值會一層層逐漸傳遞到投票系統的深處,最終被 git commit 如果使用者可以改 key1 的話,就會因為其他部分的疏忽,導致任意代碼執行的漏洞。 但是,為什麼使用者改了 key1 以後這個判斷條件還能成立? 這是因為 some_constant 不是未知的數值, 任何人只要計算 f() 馬上就可以推知 key2 了,這樣子檢查 key2 就沒有任何意義。 3. 這個系統的開發可能沒有得到足夠多人的協助、咨詢、review 如果有足夠多的 reviewer 的話,應該就不會允許那麼多 bad practice 四散各地, 該份程式碼有非常多潛在問題,不只是上面影片中提到的 exec() 問題而已。 允許 bad practice 是很不好的,今天程式跑起來沒有問題,但是隔幾個月後, 陸陸續續修改各個元件了,還能保證以後不會引爆出別的更嚴厲的漏洞嗎? 4. 這樣子的系統其實根本不算是合理的「電子投票」 現在我們看到的只是一個有電子設備輔助的投票流程, 而且這個「電子輔助」好像沒有帶給我們更多的方便。 如果只是想要咬文嚼字地片面解釋說這玩意兒就是「電子投票」當然也是可以... 但是一個正常運作的「電子投票」需要有一些良好的 "provable" properties - 某些人想要作弊?數學定理告訴我們他做不到。 - 想要驗自己的票?可以。你可以確認自己的票是否正確地被計入。 - 想要驗他人的票?多給一些條件以後,這當然也有辦法做到。 如果一個系統運行的正確性,有很多部分可以被「驗證」的話,就更能被大家接受。 而不是完全黑箱,把所有奢求的正確性都壓在一個名為「相信選舉主辦方」的籃子裡。 這樣子的「正確性」是脆弱而難以被長時間考驗的。 其實最理想的情況下,應當是使用者直接安裝軟體,在手機/電腦上直接參與投票, 請計中(orz)協助線上身份認證,或者善用 NFC 學生證悠遊卡來幫忙投票的過程。 一個好的 protocol 可以讓使用者無法在他的終端作弊,而主辦方也沒有辦法作弊。 當然了,這是一個浩大的工程,要請更多專家來幫忙才行,並不是短時間可以做到的。 5. 開放原始碼的程度其實不夠完整,普通人難以直接參與其中 只有 GitHub 上這一部分的 php 程式碼, 對於普通的 programmer 來說,還是難以幫忙「開發」、「測試」的。 應加上如何部署一台伺服器的說明、資料該如何生成、資料庫應該要有怎樣的結構等。 降低協助測試的門檻,才會有更多志願者來幫忙開發。 辛苦的核心開發人員也就不用焦頭爛耳修 bug 寫新 features 了。 如果這個系統以後還想要被使用,必定是要經過「砍掉重練」等級的大幅度更動。 不過任何的新制度也都是如此,剛開始會衝突、有異議, 必須仔細接納不同的意見,經逐步地修正、成熟化,最終才能被廣泛地接受。 如果還有許多爭議、不同的聲音時,就表示有一些根本上的問題, 所以人們才沒有被說服,所以該制度、系統就還需要修正。 不過無論如何,我們都還是由衷地感謝許多台前台後參與、幫忙的人, 因為有你們默默地無償付出,我們才能夠享受到各式各樣的福利。謝謝你們! -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.112.30.44 ※ 文章網址: http://www.ptt.cc/bbs/NTU/M.1401292521.A.34F.html

05/28 23:59, , 1F
推Q_Q
05/28 23:59, 1F

05/29 00:00, , 2F
推concise
05/29 00:00, 2F

05/29 00:03, , 3F
猛~
05/29 00:03, 3F

05/29 00:05, , 4F
推憲鍋~~~
05/29 00:05, 4F

05/29 00:05, , 5F
快推~不然人家以為我們看不懂~(雖然真的不懂QQQ
05/29 00:05, 5F

05/29 00:05, , 6F
推concise
05/29 00:05, 6F

05/29 00:06, , 7F
推這篇
05/29 00:06, 7F

05/29 00:07, , 8F
推!!!
05/29 00:07, 8F

05/29 00:07, , 9F
憲哥!!
05/29 00:07, 9F

05/29 00:10, , 10F
推! 跪惹
05/29 00:10, 10F

05/29 00:10, , 11F
跪了
05/29 00:10, 11F

05/29 00:10, , 12F
05/29 00:10, 12F

05/29 00:12, , 13F
大概看一下就看出這麼多了XD
05/29 00:12, 13F

05/29 00:13, , 14F
猛~~
05/29 00:13, 14F

05/29 00:14, , 15F
先給跪了
05/29 00:14, 15F

05/29 00:15, , 16F
推 vulnerability,也推最後結論!
05/29 00:15, 16F

05/29 00:16, , 17F
hello world~
05/29 00:16, 17F

05/29 00:17, , 18F
推結論!
05/29 00:17, 18F

05/29 00:17, , 19F
憲哥!
05/29 00:17, 19F

05/29 00:18, , 20F
05/29 00:18, 20F

05/29 00:18, , 21F
大推餡鍋~
05/29 00:18, 21F

05/29 00:18, , 22F
推!
05/29 00:18, 22F

05/29 00:23, , 23F
跪著推文啊~~
05/29 00:23, 23F

05/29 00:27, , 24F
concise.js
05/29 00:27, 24F

05/29 00:28, , 25F
05/29 00:28, 25F

05/29 00:31, , 26F
憲哥大猛
05/29 00:31, 26F

05/29 00:35, , 27F
已跪
05/29 00:35, 27F

05/29 00:35, , 28F
剛我室友問我為什麼跪著用PTT
05/29 00:35, 28F

05/29 00:35, , 29F
憲鍋~~~~!
05/29 00:35, 29F

05/29 00:37, , 30F
專業好文推~
05/29 00:37, 30F

05/29 00:45, , 31F
朝聖大神
05/29 00:45, 31F

05/29 00:46, , 32F
已跪
05/29 00:46, 32F

05/29 00:51, , 33F
餡鍋~~~~~~~~~~~~~
05/29 00:51, 33F

05/29 00:58, , 34F
05/29 00:58, 34F

05/29 01:00, , 35F
05/29 01:00, 35F

05/29 01:06, , 36F
05/29 01:06, 36F

05/29 01:07, , 37F
已跪
05/29 01:07, 37F

05/29 01:13, , 38F
RSC大大說的沒問題跑哪去了??
05/29 01:13, 38F

05/29 01:14, , 39F
05/29 01:14, 39F
還有 60 則推文
還有 6 段內文
05/29 18:23, , 100F
網路上,另外 Ethereum / BitCongress 也可參考,至少
05/29 18:23, 100F

05/29 18:24, , 101F
可以分擔一部份的驗證功能,不用全靠中央式的信任。
05/29 18:24, 101F

05/29 19:58, , 102F
感謝你的說明,其實就我所學的我會認為信任密碼學,不
05/29 19:58, 102F

05/29 19:58, , 103F
如直接從硬體上做限制,我是不太信任軟體的人,最好投
05/29 19:58, 103F

05/29 19:59, , 104F
票機使用的語言越簡單越好
05/29 19:59, 104F

05/29 20:01, , 105F
而且如果要從信任開始講起,在採用任何形式的投票時後
05/29 20:01, 105F

05/29 20:01, , 106F
就先要找到第三方可信任的公證單位,無關乎程式型態
05/29 20:01, 106F

05/29 20:04, , 107F
就像沒有wifi沒組的電腦絕對不能無線上網一樣,架構簡
05/29 20:04, 107F

05/29 20:04, , 108F
其實密碼學就是想解決如果軟體、硬體、官方都無法信任
05/29 20:04, 108F

05/29 20:04, , 109F
單,變因也越少,要去多考慮的部分也越少
05/29 20:04, 109F

05/29 20:04, , 110F
的時候該怎麼辦,所以才需要用數學證明在邏輯上
05/29 20:04, 110F

05/29 20:05, , 111F
如果有任何人做弊(投票機自己作弊、官方作弊、駭客作弊
05/29 20:05, 111F

05/29 20:05, , 112F
會被檢查出來
05/29 20:05, 112F

05/29 20:07, , 113F
抱歉,講錯,不是密碼學是軟體的安全金鑰
05/29 20:07, 113F

05/29 20:07, , 114F
當然實際上也只能作到把有任何人成功作弊的機率減小
05/29 20:07, 114F

05/29 20:08, , 115F
只信任硬體的缺點就在於如果公正單位本身作弊,毫無牽制
05/29 20:08, 115F

05/29 20:08, , 116F
的方法
05/29 20:08, 116F

05/29 20:10, , 117F
摁,看來我誤會原PO的意思了,他應該是想強調如何舉辦
05/29 20:10, 117F

05/29 20:11, , 118F
一個公正且成立的電子投票系統,我想說的是就電子投票
05/29 20:11, 118F

05/29 20:12, , 119F
系統,有更加方便且較為容易掌控狀況的選擇,至於要討
05/29 20:12, 119F

05/29 20:12, , 120F
論到單位本身舞弊,或是不公正,傳統投票也會有其問題
05/29 20:12, 120F

05/29 20:15, , 121F
另外我想說的是,就同樣是網際網路以及區網,駭客在破
05/29 20:15, 121F

05/29 20:15, , 122F
解上難度絕對有差,假設同樣的安全系統一個在開放環境
05/29 20:15, 122F

05/29 20:16, , 123F
下,他可以再任意地方連線操作,但是區域網路他必須要
05/29 20:16, 123F

05/29 20:16, , 124F
到機器上操作,就被破解的機率本身就減少許多了
05/29 20:16, 124F
yangwen5301 您好,謝謝你不吝於提供多方面的看法、討論。 關於「網路開放性」會對「安全程度」直接造成程度上的影響,你的看法是完全正確的。 如果, 存在有兩個系統,一個擺在開放網路上,一個擺在特定區域網路內, 他們能夠提供「相同的功能」,而且「理論上」他們「同樣安全」。 那麼,我們絕對就應該採用後者、區域網路內的那一個系統, 因為它的 attacking surfaces 較少。 然而一個合理的電子投票系統,終究要有一些 public API ,這些必定要讓大家可以 access 的 endpoints 就要愈簡單明瞭愈好。如你所說的,程式語言應撰寫得簡單易讀。 而且這種 public API 處,只要是會接受 input data ,就該嚴格地過濾、審視才行。 而其他只跟 server 有關的內部運算,當然就應該全面地只允許內網的存取,根本就 不必、也不應該公開。這是 common sense。愈是減少一個系統 publicly accessible 的 那些使用者不需存取的部分,這個系統就愈不容易出包。 這時候就可以被問一個問題: 那為什麼電子投票系統的主辦方『終究要有一些 public API 』呢? 因為實務上,就是幾乎沒有「所有計算都在區網內完成」這樣子的「多方」可信賴系統。 此處的重點不是區網、或公網。重點是一個協議的完成需要許多步驟, 這些步驟不可以完全只由「某一方」(例如選舉主辦方)就可以做到。 我們至少還是要有別的「信賴的基礎」才行。 例如一張晶片卡上的密碼運算、或者電腦上數位簽章的生成。 這個額外的「信賴」,是不可以只用「他人的」計算平台就做到的。 舉例來說,現實世界最傳統的身份驗證也許是簽名加蓋章。 王小明拿起一張合約以後,必須要「由他自己」來完成「簽字」與「蓋章」, 接著才會把這一張紙放進這個 blackboxed system 內,讓它去做別的事情。 這個櫃檯、這個接口就是王小明作為使用者所需要的「public API」。 反過來說,王小明走到服務人員櫃檯處,只經過簡單地寒暄問暖,就由服務人員來 單方面地就能夠「代替他」產生『此人是王小明,王小明今天想要轉帳...』之斷言。 那這個系統就沒有 (不需要) 任何實質上的 public API 。只要它想要,這個官方 它什麼都可以自己單方面地就做到。今天我們簡易版的電子投票其實有點像是這樣。

05/29 20:20, , 125F
今天使用瀏覽器作為媒介,就還要連瀏覽器可能存在的漏
05/29 20:20, 125F

05/29 20:21, , 126F
洞加以考慮,有可能駭客根本不是從破解網站本身安全性
05/29 20:21, 126F

05/29 20:21, , 127F
下手,而是從瀏覽器的漏洞進入
05/29 20:21, 127F
你好,在嚴肅地密碼分析一個系統的安全性、在制定 threat model 時,就會把你提到的 『終端的軟硬體被 compromised/hijacked (到什麼程度) 時會對安全造成怎樣的影響?』 這個問題定清楚了。 我們應該要採取那些,就算一個使用者的終端裝置(作業系統、瀏覽器)被破解到某程度 也不會影響安全性的協定。 而且要注意的是,值得被考慮 threats 必須要合理,不能無限上綱而忽略了邏輯。 舉例來說,如果一個使用者的瀏覽器被置換了、或者一個裝置上的作業系統被 root 了, 那「這一個人」就已經沒救了,我們根本不需要考慮他個人投票到底還有沒有隱私、 還能不能正常地運行,因為他使用這台電腦不管做什麼事情,都可以被第三隻手操弄; 這就像是一個人想要向一個暗戀已久的女生告白, (人性就是想要上網 但是他性格太害羞,就找他的好朋友來幫忙傳話, (但因為人類無法讀懂電磁波/ 電壓,所以就找電腦幫忙 他和這個女孩子之間所有的「通信」 (想要上網做任何事情 都是經由這位親切的好朋友之手。 (都經由這台電腦/瀏覽器 如果有一天,這個人不再是好朋友, (如果這電腦已經被植木馬... 那這個單相思的男孩是否能再與該女孩子建立良好的友誼,就已經不值得一談了。 我隨性亂想的比喻也許不適當,但是這應該勉強地有表達出那個意境。

05/29 20:50, , 128F
這個有趣
05/29 20:50, 128F
※ 編輯: concise (140.112.30.44), 05/29/2014 21:16:11 ※ 編輯: concise (140.112.30.44), 05/29/2014 21:23:53

05/29 21:52, , 129F
像前幾周IE的安全性漏洞就不是因為遭置換,而是本身就
05/29 21:52, 129F

05/29 21:52, , 130F
有問題,導致你網站在怎麼安全都沒有用,而當時資安單
05/29 21:52, 130F

05/29 21:52, , 131F
位也只有告訴民眾先不要使用IE,因為他們僅知道有漏洞
05/29 21:52, 131F

05/29 21:53, , 132F
但不知道漏洞可以做麼
05/29 21:53, 132F

05/29 21:53, , 133F
另外謝謝您詳細的說明,在相關領域長知識了:)
05/29 21:53, 133F

05/29 22:00, , 134F
所以我會認為在投票點設置公正的投票機會比用網頁好上
05/29 22:00, 134F

05/29 22:00, , 135F
許多
05/29 22:00, 135F

05/31 01:31, , 136F
再推 concise > < 偷推 Python xd
05/31 01:31, 136F
文章代碼(AID): #1JXWRfDF (NTU)