March 2016 Archives
Mon Mar 28 12:16:52 EEST 2016
Internet of Things: Hack a water plant, change chemicals
Internet of Things: Hack a water
plant, change chemicals
Source
Water treatment plant hacked, chemical mix changed for tap supplies
Hackers infiltrated a water utility's control system and changed the levels of chemicals being used to treat tap water, we're told.
Fri Mar 25 10:49:09 EET 2016
elinks and links2 don't verify ssl certificates at all on Debian 8
https://lists.debian.org/debian-user/2016/03/msg00931.html Slightly paraphrased from the cypherpunks mailing list: https://cpunks.org/pipermail/cypherpunks/2016-March/012574.html [OT] Would someone please check if links2 and elinks verify certificates on clean install of Debian 8? ---- ...elinks and links2 don't verify ssl certificates at all on Debian 8 (this got confirmation in the thread) To verify, try to open site which doesn't properly chain to trusted root, say https://cacert.org (unless you trust their root ) and check if it opens or there is error/warning. For me, on updated system, both don't verify certificates. Looks like at least ubuntu and fedora killed the elinks bug long ago. Searching the web for "$browser self signed certificate" shows some relevant results. ---- Sarcastic comment asks "when debian will learn about this".
Fri Mar 4 14:17:27 EET 2016
openssl and libressl are shipping broken in 2009 elliptic curve secp112r1
As i wrote on cypherpunks in February: openssl and libressl are shipping broken in 2009 elliptic curve secp112r1. $openssl ecparam -list_curves secp112r1 : SECG/WTLS curve over a 112 bit prime field http://lacal.epfl.ch/112bit_prime >PlayStation 3 computing breaks 2^60 barrier 112-bit prime ECDLP solved >This elliptic curve is standardized in the Standard for Efficient >Cryptography (SEC), SEC2: Recommended Elliptic Curve Domain Parameters >as curve secp112r1 and in the Wireless Transport Layer Security >Specification Good luck to those who have crypto ideals.
Thu Mar 3 11:19:52 EET 2016
According to www.virustotal.com, lists.debian.org are hosting attachment .DOC virus
According to www.virustotal.com, lists.debian.org are hosting attachment .DOC virus. Would someone confirm or deny this? Warning: DO NOT OPEN THE .DOC! Discalimer: Nothing personal against Debian https://lists.debian.org/debian-consultants/2016/01/msg00000.html links to: https://lists.debian.org/debian-consultants/2016/01/docyrW4BlUhzH.doc Submitting the last .doc URL at: https://www.virustotal.com and then going to: Go to downloaded file analysis gives: https://www.virustotal.com/en/file/c7210dc26e00a0d9f9bf8fb3b4850d52b62bb5836a7fa34bb669fc1b1553005e/analysis/1456991242/ SHA256: c7210dc26e00a0d9f9bf8fb3b4850d52b62bb5836a7fa34bb669fc1b1553005e File name: docyrW4BlUhzH.doc Detection ratio: 17 / 54 the first few results are: AVG W97M/Downloader 20160303 AVware Trojan-Downloader.O97M.Adnel.n (v) 20160303 AegisLab W97M.Gen!c 20160303 Arcabit HEUR.VBA.Trojan.e 20160303 Avast VBA:Downloader-ABC [Trj] 20160303 ESET-NOD32 VBA/TrojanDownloader.Agent.AOM 20160303 and some report it as clean. The .doc is downloadable with the same checksum.
Wed Mar 2 15:28:28 EET 2016
Literate programming in C: if(0)
I am not a C expert, but some code in libressl 2.3.2
(latest as of now) and openssl 1.0.1p (and probably later)
looks weird to me.
The code in libressl is in ssl/s3_clnt.c
984: if (CBS_len(&cert_list) < 3)
goto truncated;
1657: if (0) {
truncated:
SSLerr(SSL_F_SSL3_GET_CERTIFICATE_REQUEST,
SSL_R_BAD_PACKET_LENGTH);
}
The weird stuff is "if (0)".
Very similar stuff is in openssl.
Asked three C coders about it.
Two of them said "this sucks much".
One said "very nice idea!", denying joking.