| 02:05.09 | *** join/#qi-hardware archang (~archang@111.198.29.54) |
| 02:25.40 | *** join/#qi-hardware archang (~archang@111.198.29.54) |
| 04:11.42 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 07:46.18 | *** join/#qi-hardware tumdedum (~tumdedum@unaffiliated/espiral) |
| 10:15.22 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 11:34.15 | *** join/#qi-hardware jwhitmore (~jwhitmore@91.123.229.11) |
| 11:49.23 | *** join/#qi-hardware sb0 (~lekernel@212.91.24.78) |
| 12:49.40 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 13:21.47 | *** join/#qi-hardware fdcx (357@ceata/consiliu/FDCX) |
| 14:08.39 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 16:14.38 | DocScrutinizer05 | "fun¡" https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html |
| 16:49.41 | *** join/#qi-hardware jwhitmore (~jwhitmore@109.77.244.50) |
| 17:18.11 | DocScrutinizer05 | is this a severe security threat or just a funny sidenote? |
| 17:22.05 | wpwrak | nicely detailed report. sounds at if it might be nasty. i like this section: "Mitigations that don't work" :) |
| 17:23.07 | kyak | disturbing thing is that this flaw has been there since 2008 |
| 17:23.50 | kyak | i wonder if the attacked person would know about the attack (for example, his dns lookup utility would segfault or what?) |
| 17:24.56 | kyak | if it's just a nice way to execute code remotely from DNS server, who knows how many times this has already been exploited |
| 17:27.02 | wpwrak | the more eyes of "whitehats" that are looking at things, the more likely the fixed will be around by the time the blackhats get wind of their opportunity |
| 17:32.28 | DocScrutinizer05 | kyak: (2008) indeed |
| 17:33.00 | kyak | sure, sure, but such reports only make me more suspicious and paranoid :) |
| 17:33.03 | DocScrutinizer05 | (who knows how many times) indeed 2 |
| 17:33.42 | DocScrutinizer05 | anyway pretty 'recent' https://bugzilla.suse.com/show_bug.cgi?id=961721#c16 |
| 17:34.33 | DocScrutinizer05 | not even on security sites yet |
| 17:37.05 | kyak | https://github.com/fjserna/CVE-2015-7547 |
| 17:37.12 | kyak | people react fast |
| 17:45.38 | DocScrutinizer05 | I think it worked the other way round: they went CVE-public after the code got tested and available |
| 17:46.23 | DocScrutinizer05 | prior to that it looked like https://www.suse.com/security/cve/CVE-2015-7547.html |
| 17:46.49 | DocScrutinizer05 | >> Description ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.<< |
| 17:46.51 | kyak | ah yeah, makes sense |
| 17:48.10 | kyak | btw, the PoC dns server indeed crashes not only the test client, but any other application that attempts dns resolving (it segfaults) |
| 17:48.40 | kyak | where there is a segfault, there is an opportunity for remote code execution, if i understand correctly |
| 17:48.51 | larsc | not always |
| 17:49.37 | larsc | time to reboot all the machines though |
| 17:50.16 | kyak | this is how fast you updated? :) |
| 17:54.21 | larsc | to slow? |
| 17:54.29 | larsc | everything exploited already? |
| 17:58.04 | kyak | you still have a chance, if you reboot now! |
| 17:58.27 | larsc | already rebooted a few hours ago when the announcement came out |
| 18:07.35 | DocScrutinizer05 | how does reboot help? you need updates first, no? |
| 18:37.16 | DocScrutinizer05 | kyak: is there a *public* PoC server? |
| 18:38.32 | DocScrutinizer05 | kyak: anyway yes, when you suffered an exploit of this vuln, your app prolly would _not_ segfault |
| 18:39.07 | *** join/#qi-hardware pcercuei (~pcercuei@2a03:a680:2020:ff62:1af4:6aff:fec5:1c8f) |
| 18:39.51 | DocScrutinizer05 | as a rule of thumb when it segfaults the process terminates and can't do further malicious stuff, so exploits will try to keep the process alive |
| 18:47.47 | kyak | DocScrutinizer05: don't know if there is a public PoC server, i ran the code from github url above |
| 18:48.03 | DocScrutinizer05 | :nod: |
| 18:48.14 | DocScrutinizer05 | would be funny to have an IP ready |
| 18:49.37 | DocScrutinizer05 | of course you can run a LAN-local rogue server on your company's LAN ;-) BOFH leisure fun |
| 18:51.24 | DocScrutinizer05 | kyak: do yiu still have the thing working? could you test for me how much output a "host -a ct.de" produces before the process segfaults? does it show the DNS server IP before it gies south? |
| 18:53.04 | DocScrutinizer05 | would be a lame prank if the user could tell from stdout remanants that there's sth odd with the DNS server IP used |
| 18:53.47 | DocScrutinizer05 | sure you could handle this inside routes on router.... |
| 18:55.14 | kyak | here is what it says: |
| 18:55.18 | kyak | $ host -a ct.de 192.168.1.2 |
| 18:55.19 | kyak | Trying "ct.de" |
| 18:55.19 | kyak | ;; Warning: Message parser reports malformed message packet. |
| 18:55.19 | kyak | ;; Question section mismatch: got ./NS/CLASS25460 |
| 18:55.40 | kyak | so it actually doesn't segfault.. However, another application that uses getaddrinfo, segfaults |
| 18:56.46 | DocScrutinizer05 | hehe |
| 19:00.20 | *** join/#qi-hardware alexst (~alexander@109.188.125.7) |
| 19:03.48 | DocScrutinizer05 | now how would we make shodan search for DNS servers that publish rogue packets? |
| 19:03.50 | kyak | when quering the DNS server in TCP mode, funny thing happens |
| 19:04.22 | kyak | it spits out the 2985 bytes packet in terminal |
| 19:04.31 | DocScrutinizer05 | wow |
| 19:04.52 | kyak | dig +tcp @89.169.53.112 google.com |
| 19:05.02 | kyak | i exposed the dns server for a while :) |
| 19:05.04 | DocScrutinizer05 | that's already sort of an exploit, since you could add esc sequences and other funny stuff |
| 19:05.31 | DocScrutinizer05 | :-D |
| 19:05.54 | DocScrutinizer05 | LOL |
| 19:05.56 | DocScrutinizer05 | many thanks |
| 19:06.31 | kyak | this works for dig and nslookup, but host seems to handle this problem more gracefully |
| 19:07.32 | DocScrutinizer05 | http://paste.opensuse.org/54963443 |
| 19:07.39 | DocScrutinizer05 | yep |
| 19:07.59 | kyak | if you have dig, you can try that |
| 19:08.04 | DocScrutinizer05 | did |
| 19:08.14 | DocScrutinizer05 | fun |
| 19:08.39 | kyak | i'll shut it down now :) |
| 19:08.43 | DocScrutinizer05 | what would actually segfault? |
| 19:08.58 | DocScrutinizer05 | oooooo! |
| 19:09.12 | kyak | this is a simple app written in TCL that segfaults |
| 19:09.55 | DocScrutinizer05 | I guess it also depends on whether my app actually is supposed to use IPv6 aka AAAA, no? |
| 19:10.02 | kyak | you only need python2 to play around with the PoC dns server, so.. :) |
| 19:10.11 | DocScrutinizer05 | I know |
| 19:10.33 | DocScrutinizer05 | via internet it feels so much more 'real' ;-) |
| 19:10.37 | kyak | they mentioned in the report that disabling ipv6 won't help |
| 19:10.44 | DocScrutinizer05 | ah |
| 19:34.08 | *** join/#qi-hardware alexst (~alexander@109.188.125.7) |
| 19:39.57 | DocScrutinizer05 | allegedly a >>apt update && apt upgrade<< is due already |
| 19:40.23 | DocScrutinizer05 | I can't comment, RPM here |
| 20:02.21 | *** join/#qi-hardware lars__ (~lars@eisbaer.ursus-maritimus.org) |
| 22:19.37 | *** join/#qi-hardware Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 22:37.06 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 23:11.35 | *** join/#qi-hardware sandeepkr_ (~sandeep@111.235.64.4) |
| 23:16.38 | *** join/#qi-hardware sandeepkr__ (~sandeep@111.235.64.4) |
| 23:31.26 | *** join/#qi-hardware enyc_ (~enyc@muddle.enyc.org.uk) |
| 23:36.07 | *** join/#qi-hardware dos11 (~dos1@unaffiliated/dos1) |