#qi-hardware IRC log for Thursday, 2014-10-23

qi-bot[commit] Werner Almesberger: atusb/fw/usb/dfu.c (config_descriptor): correct alt settings off-by-one error (master) http://qi-hw.com/p/ben-wpan/b51d44205:07
DocScrutinizer05http://forkfedora.org/ is a clear evidence why systemd is crap and doesn't offer finegrained control to sysops10:49
DocScrutinizer05((<wpwrak> see, just one line. clearly, my system is superior ;-))) exactly10:49
DocScrutinizer05>>The support for ARMĀ® TrustZoneĀ®,<< WAAAAAAHHHH!   http://inversepath.com/usbarmory10:57
whitequarkI don't see a problem10:58
DocScrutinizer05reflex on reading "TrustZone"11:05
DocScrutinizer05TrustZone is siamese twin of trusted computing and aegis11:06
DocScrutinizer05[2014-10-23 Thu 13:07:04] <DocScrutinizer05> aegis11:07
DocScrutinizer05[2014-10-23 Thu 13:07:05] <infobot> http://www.developer.nokia.com/Community/Wiki/Harmattan:Developer_Library/Developing_for_Harmattan/Harmattan_security/Security_guide , or "The purpose of this framework is: ... to make sure that the platform meets the requirements set by third party software that requires a safe execution environment.", or http://en.wikipedia.org/wiki/Trusted_Computing#Criticism, or  http://en.qi-hardware.com/w/11:07
DocScrutinizer05TZ is not helping user to install a secure system for themselves. TZ is designed to protect the system from user, so when user also is "owner" of of the trusted environment, the whole TZ is pointless and could get implemented in simpler more established and mature ways11:11
DocScrutinizer05or, to re-qiote with emphasis added: >>...The purpose of this framework is: ... to make sure that the platform meets the requirements set BY THIRD PARTY SOFTWARE...<<11:15
DocScrutinizer05IOW make sure that the 3rd party software doesn't face a system that got "tampered" by user11:16
DocScrutinizer05to put it straight: your 3rd party MP3-player is running in secure environment so the content provider can be sure you have no means to redirect the decoded audio stream to any other destination than the DAC and 3.5mm headset output11:20
DocScrutinizer05since *all* processes running on your system got approved and signed by 3rd party. So you got no tool to do such redirect of audio data. When you're the owner of the "3rd party" signature key then what's the purpose of whole trustzone?11:21
DocScrutinizer05you cannot protect the system from yourself11:23
larschttps://lkml.org/lkml/2014/10/23/129 ;)11:27
DocScrutinizer05wtf is this?11:30
whitequarkDocScrutinizer05: bullshit11:32
whitequarkTZ is a tool. if the user has a key, it works in favor of user.11:32
whitequarkit is no different than having root on device.11:32
DocScrutinizer05patch to augment kernel driver with a self destruction function for counterfeit FTDI chips?11:32
DocScrutinizer05whitequark: EXACTLY11:33
DocScrutinizer05thus it's completely useless cruft11:33
whitequarkDocScrutinizer05: nope11:33
whitequarkit has the same function as separating root and nonroot11:34
DocScrutinizer05yes, exactly. And since we already have such separation in all decent OS, why do we need TZ?11:34
whitequarkbecause if you have regular user on linux, getting root is *trivial*11:34
whitequarklocal privilege escalation bugs on linux count in hundreds11:34
DocScrutinizer05bugs in TZ count in the zillions11:35
whitequarkI don't disagree, just haven't seen them so far11:35
DocScrutinizer05google for Nokia harmattan aegis11:35
DocScrutinizer05TZ by no means is any intrinsically more safe than calssical root/user separation and privilege management. Just way more complex, and with added benefit that you could deprive user from becoming root *ever* on own device11:36
whitequarkyou already have that issue11:37
whitequarkI mean, on modern smartphones *without* TZ you can commonly only become root via bugs11:37
whitequarkand you know what? if a "jailbreak" app can become root, it means that any malware whatsoever can become root too11:38
DocScrutinizer05they have other implementations of same concept11:38
whitequarkthis is why iPhone security works, and Android is a shithole11:38
whitequarkone of reasons, at least11:38
whitequarkDocScrutinizer05: no, I mean, even if you only implement this in software, you have the same situation11:39
DocScrutinizer05TZ is cruft11:39
whitequarkstill not convinced11:39
whitequarkTZ is basically cut down virtualization11:40
whitequarkwhatever runs in TZ is a "hypervisor", the rest is a "guest"11:40
whitequarkvirtualization-based sandboxes have a much better track record than OS-based11:40
whitequarkXen has had around fifty advisories through its entire life, only maybe five of them can give you root11:40
DocScrutinizer05and unlike usual virtualization you can run TZ without ever sharing the secret key needed to sign stuff11:40
whitequarkthis is not a problem of TZ. this is a problem of shitty vendors.11:41
DocScrutinizer05and that'S the ONLY difference between TZ and a usual system11:41
whitequarkbetween TZ and system with virtualization? yes11:42
whitequarkbetween TZ and system without virtualization? no11:42
DocScrutinizer05as soon as you hand out the TZ root secret key, there's no difference to any other supervisor slution of which there are 5 dozen out there11:42
whitequarkthat I agree11:43
DocScrutinizer05just that TZ is incredibly complex and cumbversome to maintain11:44
whitequarkhm, I've talked with someone developing for TZ and they were ok with it11:44
whitequarkbut I don't know for sure11:44
DocScrutinizer05sure, it's ok for you when you're the "3rd party" that actually owns the key, or you are simply not bothering about who's administrating the target platform and you just get your app you developed to owner of TZ root key for signing it11:46
DocScrutinizer05the point is that *all* your system, from bootloader to last cheesy app, needs to get signed by TZ root key11:47
DocScrutinizer05and you need a list of privileges allowed for every app, that gets part of such signature11:47
whitequarkhuh? I don't think so, you don't need to sign untrusted code11:48
whitequarkit's basically the point11:48
DocScrutinizer05this is how nokia decides what you may or may not run on your N911:48
whitequarksure, you could use TZ in such fashion if you really want, but nothing in TZ inherently requires it11:48
DocScrutinizer05but that's the *only* purpose of TZ11:48
DocScrutinizer05every app developer needs his app to get signed at Nokia, or it won't run on any N911:50
DocScrutinizer05if you hand the key out to everybody, you could as well stop using TZ at all, to start with11:52
DocScrutinizer05handing an individual key to every single N9 owner would not differ from simply giving them the root password and not using TZ at all11:53
DocScrutinizer05having one common publicly known key is absolute nonsense11:53
DocScrutinizer05whole trustzone is only for *one* purpose: to allow vendor to have total control over the devices they sell11:55
DocScrutinizer05it really has no other purpose or benefit11:55
whitequarkas far as I see TZ is merely a hardware-assisted virtualization feature11:58
wpwraklarsc: it is not targeted against ze user. all i do is make sure ze rockets go up. where ze come down is not my problem ;-)12:27
ysionneau13:38 < whitequark> this is why iPhone security works, and Android is a shithole < why is iPhone any better?12:44
whitequarkysionneau: it's generally pretty hard to jailbreak an iPhone12:45
whitequark(it doesn't matter to this discussion whether this is achieved via good coding practices, virtualization, TZ, whatever.)12:45
ysionneauisn't it the same principle? you get root through security bug12:45
whitequarkif you can't do it, then malware can't do it as well12:45
whitequarksure. but jailbreaking android devices is trivial12:45
ysionneauI honestly don't know iPhone world12:46
whitequarkthis means you can't rely on its sandboxing at all.12:46
ysionneauhaven't all iPhones been rooted?12:46
whitequarkmost jailbreaks require explicit physical user action, like tethering it to a PC and uploading something12:46
ysionneaumaybe with a few months lag at each new iOS release12:46
ysionneauoh ok12:46
ysionneauI didn't know that12:46
whitequarksince I think iOS 4 or something?12:46
ysionneauso no kernel exploit or something12:46
ysionneauwell, not exploitable from app12:47
whitequarkactually, not quite, you usually need multiple exploits12:47
whitequarkbut the days of jailbreaks from inside the device are gone12:47
whitequarkand this is good12:47
ysionneauindeed Android has and had tons of vuln accessible from low privilege app12:47
ysionneauhow do they achieve that?12:47
ysionneauvery low system call attack surface,12:47
whitequarkwell, for example, you can't mark data pages as executable12:48
whitequarkso no JITs, but also less exploits12:48
whitequarkthen they have ASLR12:48
whitequarkkernel ASLR, too12:48
ysionneaumodern Android have ASLR pretty much everywhere I think12:49
whitequarkyes, and then 80% of vendors put some shitty library with ASLR disabled12:49
whitequarkalso likely vulnerable12:49
whitequarkwhich defeats the purpose.12:49
whitequarkalso not sure about kernel ASLR12:50
ysionneaunot sure about that either12:50
wpwraklarsc: seems that FTDI also go one step further and actively sabotage such chips: (in german) http://www.heise.de/newsticker/meldung/FTDI-Proaktive-Fake-Chip-Abwehr-2430780.html12:59
wpwrakwell, maybe that will make people realize they don't need FTDI chips. they've been a bad choice for a long while already and it seems it just got a little worse13:02
wpwrakand very badly documented13:05
wpwraki once tried to use one of their chip to make an in-circuit programmer. failed miserably because i couldn't toggle pins reliably. never found out whether it was just a documentation issue or a silicon limitation. lesson learned: use an USB MCU and accept that you need something already existing to bootstrap it.13:06
wpwrakso with ftid you're basically screwed if you leave the well-traveled path. and they also did a number of stunts like undocumented EEPROM content that took forever to reverse-engineer.13:07
larscwpwrak: that kernel patch was a reply to the FTDI diver changes13:08
wpwrakso it's quite ironic that their chips are so popular in the free and open hardware development scene. these are not our friends.13:08
wpwraklarsc: ah, so it was meant to be a joke. and indeed, it does seem to actively alter the Vendor ID.13:11
wpwraknow this is nice ;-) http://marc.info/?l=linux-usb&m=141403510729881&w=213:13
larscyea, although it took me a while to realize that it was a joke13:15
wpwrakyeah, the description doesn't make it clear that it actively breaks things13:16
wpwrakgreg got it, though. the checks and balances are working ;-)13:17
larscyea, he's a bit smarter than me13:24
wpwrakor he had some early warning :)13:29
DocScrutinizer05please update me what i missed13:30
DocScrutinizer05looked to me like I said: patch to augment kernel driver with a self destruction function for counterfeit FTDI chips13:30
whitequarkit was a parody13:30
whitequarkthe patch author works for TI, not FTDI13:31
DocScrutinizer05well, that's the question13:31
wpwrakhelping the competition to sink their own product. nice ;-)13:31
DocScrutinizer05it's a parody when the author could be sure it won't get committed to linux kernel. Otherwise it's hilarious but not a joke13:32
whitequarkif it would be committed to linux kernel, the linux kernel maintainers would be idiots13:32
DocScrutinizer05of course unless the code kills original FTDI chips and not the counterfeit ones13:32
whitequarkand anyone could commit more malicious stuff in the blink of an eye13:33
whitequarklike "goto fail"13:33
DocScrutinizer05LOL http://marc.info/?l=linux-usb&m=141405129201389&w=213:38
larscwho says that this isn't possible already ;)13:38
DocScrutinizer05((linux kernel maintainers would be idiots)) well, I wouldn't bet on NONE of them actually is ;-)13:41
whitequarkthen it is an excellent litmus check13:42
whitequarkif a maintainer commits a patch like that, they stop being a maintainer13:42
DocScrutinizer05hehe indeed13:42
DocScrutinizer05actually GKH got a point in "better had saved that for April 1." anyway13:43
larscmjg actually did that recently (Accept a stupid patch, than quit being a maintainer)13:43
DocScrutinizer05on IRC you could earn permaban for stuff like that (rm ;- r f )13:44
whitequarklarsc: mjg?13:44
whitequarkI mean, what patch?13:44
whitequarkI know who mjg is13:44
DocScrutinizer05me not13:44
larscwhitequark: https://lkml.org/lkml/2014/8/20/57413:50
wpwrakhmm, what was the problem ? the (ret) -> (ret != 0) ?13:55
wpwrakreferring to this: https://lkml.org/lkml/2014/6/13/57013:55
whitequarkcommit name indicates it wasn't ready for mainline13:55
larscgoogle Nick Krause13:57
wpwrakNick Krause is an American film and television actor13:57
larscgoogle Nick Krause Linux13:57
wpwrakso mjg is handing him a success ? miss a patch and the maintainer self-destructs ?14:02
rjeffrieswpwrak may or may not appreciate this gadget: https://www.cnx-software.com/2014/10/22/usb-armory-is-an-open-source-hardware-freescale-i-mx53-dongle-for-security-applications/15:18
larscDocScrutinizer05 for sure does not appreciate it ;)15:22
wpwrakrjeffries: yes, i've seen it. looks like a nice platform for certain functionality. e.g., crypto containers and such.15:27
rjeffrieswpwrak I did not take time to look at price of that dongle, but assume it is low cost. I am a poor judge of open-ness but it seems they are trying to have an open hardware platform.19:49
rjeffriesa mumble about security and the password morass: anelok seems to be promising as best I can tell. I wonder if the following use case is supported: using anelok strictly as a secure password vault. That's how I use the (open) Android program Universal Password Manager (UPM). Yes, I then type in a password manually, and yes that fact influences my password construction a bit. 20:02
rjeffriesSo the question I have is if a user wants a small relatively secure password vault and accepts they will look up passwords and type them in, how well will anelok support that workflow? It assumes a simple easy fast seach to find teh desired entry.20:04
DocScrutinizer05larsc: nobody needs to use TZ cruft. And actually TZ comes with a side effect of usually no access to the secured conzent via booting a rescueOS or by flashing a new kernel. Usually those HS devices (TZ-enabled) only allow flashing new stuff after _complete_ erasute, which is absolutely fine for stuff like crypto containers20:13
DocScrutinizer05not like a 89c1051 couldn't do same ;-)20:14
Action: DocScrutinizer05 idly wonders who's "inverse path" and what they actually do20:29
nicksydneywpwrak: you must be happy now http://dangerousprototypes.com/?p=8395022:10
wpwraknicksydney: cern are doing good work. what i don't like so much is that kicad is breaking the old "user experience". also, the newer versions are much slower than the older ones23:01
nicksydneywpwrak: is it because they are relying too much on GPU processing ?23:02
nicksydneyto make the rendering faster ?23:02
whitequarkGPU is certainly the way to go23:03
wpwrakyes, and the GPU-based part doesn't seem to be very usable for manual routing. so for that one has to use the old interface, which is now very slow23:03
wpwrakwhitequark: dunno. it's not as if the drawing operations would be complex. and doing the same work used to be much faster in the past. on the same hardware.23:07
wpwraki think it's mainly C++ bloat23:07
whitequarkwpwrak: sure it's not your graphic drivers?23:11
whitequark(integrated intel should be perfect for this kind of stuff, not sure what you use though)23:11
wpwrakmy pc from an earlier generation. has radeon and nvidia.23:12
whitequarkah, so nv.23:12
nicksydneywpwrak: that's the same issue i had previously when using the master branch23:23
nicksydneyi'm using AMD23:24
--- Fri Oct 24 201400:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!