Thre is a bug in sudo before 1.8.28. The bug, basically, involve UID validation where user ID -1 or 4294967295 could allow a user with sudo privilege to run command as root, even the Runas specification explicitly disallow root access.
For example, specify Runas in /etc/sudoers like this:
test ALL=(ALL,!root) /usr/bin/whoami
Password authentication depends on user input. To make it safe, one of the requirement is that you need to do it safely and quickly enough and hope that nobody could catch what you type on the keyboard.
Nowadays, we can’t hope such.
With naked eyes, we can simply read gestures, types, presses most of people do when they unlock their phone. With cameras, you can replay – in slow motion.
This is not new at all. Though, nowadays, cameras are everywhere, videos are publicly available, big data, machine learning, if you put them together, you can extract a person’s password from such sources.
Many IT vendors already knew this for years. That’s why they started pushing biometrics like fingerprint scans, face recognition in their products, and encourage their users to use it – at least, as one factor of their authentication methods.
IMHO, the password authentication should completely be eliminated. We should not even use it as a factor in authentication ecosystem – it must die.
Let me hope it will – soon.
BTW, researches on replacing password authentication are very welcome. :)
The Go match between AI and pro is very interesting. I’m a fan of igo/weiqi/baduk. I used to play constantly, and was rated SDK (single-digit kyu). Also, as a computer scientist, Go is the only board game that the best human can defeat the best AI.
Well, not anymore.
AlphaGo, with deep/machine learning, was well-trained, and beat one of the world’s best professional, Lee Sedol 4-1 (game records [1] [2] [3] [4] [5]).
With the advancements of methods, algorithms, and abundant resources of Google/Alphabet, I would not surprise much about the result. What surprised me was that it came much earlier than I expected.
With such advances in AI, many people start discussing about AI/robots will take over the planet – like Terminator’s SkyNet, or the Matrix. I think we, humanity, should must be very careful about using AI. We all should must know that, in the end, human cannot be superior the AI.
Biologically, we just can’t.
Many scientists knew that. For decades, groups of researchers tried to come up with the ultimate laws to control AI to ensure the public safety; something like Asimov’s Three Law of Robotics in the real world. There are many recent papers published in the area called “Ethics of Artificial Intelligence“. Having ethics / laws is great, I totally agree with that. But, then again, just like any laws humanity came up with – religions, rules, laws, ethics, orders, you name it – the problem is the control.
Controls, including ones that will apply over AI, depend on human. But, humans are radical. They are uncontrollable. I’m pretty confident that, even with the ultimate laws of robotics, ones will build AI without the laws embedded.
The threat against humanity is, unfortunately, not the AI, but humans themselves.
Qualys SSL Labs provides a SSL Server Test for awhile. You can rate your web site at https://www.ssllabs.com/ssltest
To get rating “A”, there are few straightforward tricks:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2
ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
add_header Strict-Transport-Security max-age=31536000;
Optionally,
ssl_dhparam /etc/ssl/private/dhparam.pem; ssl_stapling on; ssl_stapling_verify on;
First, install libpam-ldap
# apt-get install libpam-ldap
Config ldap:// properly. This will add ldap backend to PAM.
Now, create a file /etc/pam.d/nginx
@include common-auth @include common-account
This will add nginx service in PAM.
Then, config your nginx to enable HTTP basic authentication using auth_pam and PAM service name “nginx”
location /someplace {
auth_pam "Restricted Area";
auth_pam_service_name nginx;
}
Restart nginx. Done.
วันนี้ได้รับแจ้งจากผู้ใช้เรื่อง https ของ มข. ตรงช่อง URL ขึ้นเป็นสีเหลือง (yellow padlock) อย่างที่ปรากฏในภาพบน แทนที่จะเป็นสีเขียว (green padlock) เหมือนทุกครั้ง
เท่าที่ตรวจสอบ พบว่าเกิดกับ Google Chrome / iOS บางรุ่น และเป็น bug ในส่วนการตรวจสอบ certificate chain ของ Google Chrome / iOS เอง
Google Chrome / iOS รุ่นถัดไปน่าจะแก้ไข bug นี้
ระหว่างนี้ ถ้าต้องการยืนยันเพื่อความมั่นใจ ให้แตะที่ icon สีเหลืองตรงช่อง URL และดูรายละเอียดที่ปรากฏตามภาพข้างล่าง
ถ้า icon ที่หนึ่งและสอง เป็นสีเขียว (อย่างเช่น ที่ปรากฏในภาพ) ก็ถือว่ามีความปลอดภัยแล้วล่ะ
Reference:
https://code.google.com/p/chromium/issues/detail?id=467084
https://productforums.google.com/forum/#!topic/chrome/lQ6x51gPR3Y
Superfish กลายเป็นข่าวดังเมื่อไม่นานมานี้ เนื่องจากมีคนพบว่า Lenovo preload adware ตัวนี้มาจากโรงงาน ว่าง่ายๆ มันทำ targeted/personalized ads โดยเอาข้อมูลการใช้งานของผู้ใช้ไปวิเคราะห์ดูว่าน่าจะส่งโฆษณาอะไรดี
แต่ความน่ากลัวของ Superfish มันอยู่ที่กลไกการทำงานของมัน เพราะจะทำแบบนั้นได้แปลว่ามัน intercept ข้อมูลที่ผู้ใช้เยี่ยมชมเว็บต่างๆ ซึ่งก็คือมันทำงานเป็น Man-in-the-Middle นั่นแหละ
ที่แสบคือมัน intercept HTTPS ได้ โดย browser จับผิดไม่ได้
เท่าที่เข้าใจ หลักการของ Superfish คือ ทำตัวเองเป็น root CA ที่ browser เชื่อถือ ด้วยการใช้ adware เป็นตัวฝัง root certificate ไว้ใน browser พอผู้ใช้เข้าเว็บที่เป็น HTTPS มันก็จะ intercept ถอดรหัส เก็บข้อมูล ใช้ key ใน root certificate ของมันเอง + hostname ของเว็บมาสร้าง certificate ใบใหม่ แล้ว establish SSL กับ browser ในเครื่อง
ผล: browser จะไม่เตือนอะไรเลย เพราะ certificate ที่ใช้สร้างด้วย trusted root CA certificate ที่ฝังใน browser และ hostname ก็ตรงกับใน URL เข้าเว็บไหนก็เขียว กุญแจก็ล็อค เผลอๆ เข้าพวกที่ใช้ self-sign certificate ก็ยังจะเขียวเลย :P
แปลว่าข้อมูลจะถูกดูดออกไปได้โดยผู้ใช้ไม่รู้ตัว ถึงแม้จะเป็น HTTPS แล้วก็ตาม รั่วได้หมดทั้ง password, credit card และข้อมูลส่วนตัวอื่นๆ ที่ปกติไม่อยากให้ใครรู้
เคส Superfish เกิดกับ MS Windows เท่านั้น :P
อธิบายเรื่อง heartbleed
1. ใน SSL/TLS ใหม่ๆ มีฟีเจอร์ heartbeat สำหรับ maintain session เพื่อลด cost ในการ reestablish secure connection
2. heartbeat ใช้วิธี request / response
3. request ที่ส่งส่วนนึงคือ data, byte length ของ data / response ส่วนนึงคือ data และ byte length ของ data ที่ได้รับ
4. ปัญหาคือ openssl implement heartbeat โดยไม่มีการตรวจสอบ byte length ว่าสัมพันธ์กับ data (/me .. ชิบหายแล้ว !) เวลาสร้าง response openssl จะเอาค่า byte length ที่ได้รับมาใช้ดื้อๆ
5. จาก 4 เราสามารถสร้าง request ขนาด 1 byte โดยระบุ byte length ว่ายาว 64 kB ก็ได้ และ openssl ก็จะเชื่อว่าเป็น 64kB “และ” จะสร้าง response กลับโดยอนุมานว่า data มีขนาด 64kB
6. สมมติว่า openssl ได้ request ตามข้อ 5 openssl จะ buffer data 1 byte ใน request ไว้ใน memory และจำว่ามันยาว 64 kB
7. เมื่อ openssl สร้าง response ก็จะนำข้อมูลใน buffer มาใช้ แต่เนื่องจากมันเชื่อว่าข้อมูลยาว 64 kB มันเลยสำเนาข้อมูลออกมาจาก buffer 64 kB เพื่อสร้าง response .. แปลว่ามันสำเนา (access) ข้อมูลเกินจากที่ควรจะเป็น ทำให้คนที่ request ขโมยข้อมูลจาก memory ของ openssl ได้
8. ข้อมูลใน memory อาจจะมี session key / private keys / sensitive info ที่ buffer ไว้สำหรับ ciphers ที่กำลังทำงานขณะนั้น
9. ถ้าได้ private key ข้อมูลที่วิ่งผ่าน SSL/TLS ก็จะสามารถถอดรหัสได้โดยง่าย รหัสผ่าน / ข้อมูลที่เคยหวังว่า SSL/TLS จะปกป้องได้ก็จะรั่วได้หมด ทุก services ที่พึ่งพา openssl จะเสมือนเป็น plaintext protocol
10. 60-70% ของ SSL/TLS ที่ใช้บนโลกนี้ ใช้ openssl รวมถึง internet banking บางเจ้า / cloud console แทบทุกเจ้า แต่ openssl ที่เป็นปัญหาอยู่ในรุ่น 1.0.1 ถึง 1.0.1f เก่ากว่านี้รอด ใหม่กว่านี้ก็รอด
11. ทางแก้ปัญหา อย่างน้อย ต้อง patch / upgrade เป็น openssl ใหม่ + เปลี่ยน certificate ใหม่ทั้งหมดทุก services ที่พึ่ง openssl เพราะ private keys อาจจะรั่วไปแล้ว / เปลี่ยนรหัสผ่านทุก users ที่ใช้บริการผ่าน services เพราะมันอาจถูกถอดรหัสไปได้หมด
12. provider ที่ users เยอะๆ ถึงเต้นกันใหญ่ ทั้ง facebook, google, amazon, … ถ้าคิดว่ามันเรื่องเล็ก ไม่ใช่เรื่องเร่งด่วน ไม่ควรเป็น admin
อ่านที่ พี่เทพ blog เรื่องการจัดการ security ในเดเบียนแล้ว ระลึกได้ว่าเคยหลุดเข้าไปในขั้นตอนการจัดการ security ของ FreeBSD เมื่อหลายปีก่อน พบว่ามีลักษณะใกล้เคียงกัน .. จะว่าไปแล้วมันก็เป็น practice อย่างนึงที่วัฒนธรรม FOSS นำมาปรับใช้ในการจัดการเรื่อง security เกือบทุกชุมชน
บ่อยครั้งที่ผู้สนับสนุน FOSS นำเอาเรื่อง security มานำเสนอว่าปลอดภัยกว่า proprietary/commercial software ในขณะที่กลุ่ม proprietary/commercial software ก็แย้งว่าการเผยซอร์สเป็นการเผยไต๋ทำให้โดนโจมตีได้ง่าย
ว่ากันตามตรง ช่องโจมตีมักจะพบโดย black hat มากกว่าพบโดยการรีวิวซอร์สโดย hackers (จริงๆ) หรือ maintainers และในปัจจุบันช่องโจมตีไม่ได้หากันที่ซอร์ส แต่หาจากไบนารีตรงๆ โดยเครื่องมือจำพวกดีบักเกอร์เนื่องจากผู้โจมตีจำเป็นต้องได้ข้อมูลขณะที่ไบนารีนั้นกำลัง execute จึงจะทำ bypass, overflow, หรือ กำหนด condition ได้ถูก ดังนั้นในแง่การหาช่องโจมตีจะเห็นหรือไม่เห็นซอร์สจึงไม่ใช่ประเด็นเท่าไหร่นัก และกลายเป็นว่าใช้ซอฟต์แวร์เผยหรือปกปิดซอร์สมันก็แย่พอๆ กัน แต่ในแง่การพัฒนา ปรับปรุง แก้ไข หลักการของ FOSS ที่เผยซอร์สมีศักยภาพที่ดีกว่า หากผู้ใช้หรือชุมชนมาช่วยรีวิวได้มากพอ มัน ‘ควรจะ’ พบจุดบกพร่องได้เร็ว และได้รับการแก้ไขได้ไวกว่า .. Elias Levy (Aleph One / Bugtraq) เคยพูดเรื่องนี้ไว้ว่า
“Open Source Software certainly does have the potential to be more secure than its closed source counterpart. But make no mistake, simply being open source is no guarantee of security.”
FOSS ไม่ได้ปลอดภัยกว่า แต่มีศักยภาพที่จะปลอดภัยกว่า
นึกถึง
ทำได้ก็ลด security bugs/vulnerabilities ไปได้เพียบแล้ว :)