Re: On blindly running code
On Fri, Oct 18, 2019 at 11:23 PM wrote: > > Frank Beuth writes: > > On Fri, Oct 18, 2019 at 11:54:18AM +0100, cho...@jtan.com wrote: > > >Virtualisation is not a panacea. I have managed to achieve data loss > > >through destructi > > ve actions taken within a "safe" virtualised sandbox. > > > > How did you manage that feat? > > Basically assuming "safe" then taking actions to subvert that, namely > mounting an SMB share within the VM. rm(1) does not discriminate. My own > fault obviously but it's notable that the "virtual environment == safe" > assumption was shattered so effectively, so easily, and by actions which in > most circumstances would be benign. > Been there, done that, got the t-shirt. Only in my case it was a mounted VFAT volume in my home directory. Oops. Praise the programmer for undelete. -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: On blindly running code
On Fri, Oct 18, 2019 at 01:20:33PM +0100, cho...@jtan.com wrote: Frank Beuth writes: On Fri, Oct 18, 2019 at 11:54:18AM +0100, cho...@jtan.com wrote: >Virtualisation is not a panacea. I have managed to achieve data loss through destructi ve actions taken within a "safe" virtualised sandbox. How did you manage that feat? Basically assuming "safe" then taking actions to subvert that, namely mounting an SMB share within the VM. rm(1) does not discriminate. My own fault obviously but it's notable that the "virtual environment == safe" assumption was shattered so effectively, so easily, and by actions which in most circumstances would be benign. Poking holes in parachutes has been known to impair their function, yes...
Re: On blindly running code
Raul Miller writes: > My mental model of computer security often approximates putting a bank > vault door on a picket fence (and maybe setting up a sniper to stop > people from climbing over the door). But in layers. One of them will work right? It's defense^Wobscurity in depth. > Doesn't mean that the exercises weren't worthwhile, but in my opinion > we put far too little effort into making people comprehend what's > going on. > (Not entirely true, and raspberry pi/arduino I think it's very true. Case in point is ssl/pkc. For a while I refused to believe that I understood public key cryptography because it was so incredibly simple and yet all the documentation I'd seen up to that point had been impenetrable, contradictory, incomplete or some mixture of the three. I can count on one hand the number of people I've worked with who understood it rather than relying on copy pasta. Hence LetsEncrypt now exists. The lack of understanding is tangible and worrying. > but I sometimes worry about the lack of > focus on physical and electronic abstraction layers.) Already lost. There's nothing real about an abstraction layer. We can't reconcile with them in the real world. Instead we ascribe human-like attributes to automota which can only mock the appearance without any of the substance. "Smart" devices are smart like a parrot that's learned how the crackers come and just as vindictive yet they have in less than half a generation become embedded into our lives and societies as though they are godlike in their prescience. They now drive our death machines around. We have machines with the intelligence of a parrot and the attention span of a toddler driving multi-tonne killing machines at upwards of 70mph. That's insane. Abstraction layers are all very well when developing algorithms but when the rubber hits the road the CPU's gonna do what the CPU's gonna do and if you don't know what it can, will and does do then no abstraction layer is going to help you. We need to trust the machines like the badly-treated rottweiler who's muzzle we can't remove and who's looking at our children hungrily, not like the adorable harmless puppies the devices try to act as and who's place they currently occupy. That is the fundamental flaw in our collective security model. I handle it by understanding the technology so I can work around the holes. Those who can't or won't need a better model than "aww! cute!" Anyway I didn't mean for this to turn into a rant so I'm done. Well I did because I started it as one but it was meant to be a rant about administrators and developers who don't understand what they're doing but do it anyway and not the sorry state of IT security around the world and how it's turning society into the worst possible bastard child of George Orwell and Aldous Huxley. That would require far more space than this mailing list allows to do it justice. > recovering backups (I've seen backup systems which never worked where A pile of data may look like a backup but without a proven recovery strategy it's just a pile of data. Matthew
Re: On blindly running code
On Fri, Oct 18, 2019 at 8:23 AM wrote: > That's not to even start on the fact that it's little more than process > switching and virtual memory on steroids, so the extra seperation on top of > what the OS already provides is little more than smoke and mirrors. My mental model of computer security often approximates putting a bank vault door on a picket fence (and maybe setting up a sniper to stop people from climbing over the door). Doesn't mean that the exercises weren't worthwhile, but in my opinion we put far too little effort into making people comprehend what's going on. (Not entirely true, and raspberry pi/arduino communities for example have been putting in some useful efforts. OpenBSD is no slouch, either, but I sometimes worry about the lack of focus on physical and electronic abstraction layers.) In my opinion, good computer security typically involves multiple pieces of independent hardware (and good practices such as making and recovering backups (I've seen backup systems which never worked where that wasn't detected until they were needed because no one thought to test the backups (... then again, I've also seen multiple redundant systems taken out by a single stroke of lightning because they were in the same room... ))). Anyways, we do what we can, and no security can be perfect, but also the existence of flaws is not, in and of itself, a reason to give up. Better to classify that as "room for improvement". (Also, sad to say, but: smoke and mirrors can sometimes be useful -- if you have enough other measures in place.) Thanks, -- Raul
Re: On blindly running code
On Fri, Oct 18, 2019 at 11:54:18AM +0100, cho...@jtan.com wrote: Virtualisation is not a panacea. I have managed to achieve data loss through destructive actions taken within a "safe" virtualised sandbox. How did you manage that feat? If the only thing that can demonstrate what a piece of code does is to run it blindly, rather than to work it out by reading and study, then the code is faulty and should be replaced. I expect the code I use to be in this state before I will even begin to trust its documentation because if the developer doesn't understand what it does how can his explanation be at all enlightening? Executing code in a test environment should only be to *verify* the assumptions and calculations you have *already made*. In the world of malware analysis, running code blindly (in a virtual machine) in order to figure out what it does (by comparing "before" and "after" snapshots) is standard operating procedure. (standard operating procedure doesn't necessarily make it a good idea, but it is what it is)
Re: On blindly running code
Frank Beuth writes: > On Fri, Oct 18, 2019 at 11:54:18AM +0100, cho...@jtan.com wrote: > >Virtualisation is not a panacea. I have managed to achieve data loss through > >destructi > ve actions taken within a "safe" virtualised sandbox. > > How did you manage that feat? Basically assuming "safe" then taking actions to subvert that, namely mounting an SMB share within the VM. rm(1) does not discriminate. My own fault obviously but it's notable that the "virtual environment == safe" assumption was shattered so effectively, so easily, and by actions which in most circumstances would be benign. That's not to even start on the fact that it's little more than process switching and virtual memory on steroids, so the extra seperation on top of what the OS already provides is little more than smoke and mirrors. > In the world of malware analysis, running code blindly (in a virtual > machine) in order to figure out what it does (by comparing "before" and > "after" snapshots) is standard operating procedure. > > (standard operating procedure doesn't necessarily make it a good idea, > but it is what it is) There's something to be said for it if your constraints are sound. I doubt a half-decent malware analyst isn't both extremely paranoid about their testing gig and still won't run code without at least a cursory glance at the disassembly. Consider that without access to the source code the game changes considerably. Matthew
Re: On blindly running code
Shane Lazarus writes: > Heya > > My own experience agrees with you with regards to any system in production. > > However, it is also my experience that nothing demonstrates the > difference between what should happen and what actually occurs better > than running the code and seeing the aftermath. > > Thankfully, virtualisation makes things much simpler these days, and > running through everything on a clone prior to even considering steps > on the production system is consequently highly recommended. Virtualisation is not a panacea. I have managed to achieve data loss through destructive actions taken within a "safe" virtualised sandbox. If the only thing that can demonstrate what a piece of code does is to run it blindly, rather than to work it out by reading and study, then the code is faulty and should be replaced. I expect the code I use to be in this state before I will even begin to trust its documentation because if the developer doesn't understand what it does how can his explanation be at all enlightening? Executing code in a test environment should only be to *verify* the assumptions and calculations you have *already made*. A development, test or other environment is as much "in production" as any other, because if they somehow become unavailable then someone, somewhere is losing money. And if you took it down because you didn't know what code you were executing was going to do then it's your fault. Matthew
Re: On blindly running code
Heya My own experience agrees with you with regards to any system in production. However, it is also my experience that nothing demonstrates the difference between what should happen and what actually occurs better than running the code and seeing the aftermath. Thankfully, virtualisation makes things much simpler these days, and running through everything on a clone prior to even considering steps on the production system is consequently highly recommended. Shane On Fri, Oct 18, 2019 at 11:19 PM wrote: > > With regards to recent discussion, here is a little anecdote that came out of > the 6.5 to 6.6 upgrade. > > On one machine I run bitlbee, an IRC:IM gateway. After upgrading all the > ports it left suggestions in the form of copy pasta commands to run to > complete the upgrade process, as it does. One of these was rm -rf > /var/bitlbee/*. > > Had I been so stupid as to just run the command, or if the hyper-complicated > upgrade script required to support every possibility included a single > mistake, all of the settings to connect to my IM accounts (currently > constituting the only place some ancient passwords are guaranteed to be > saved) would have been lost, where in fact what I had to do about those files > was absolutely nothing. > > There is no fault here. The wording is something like 'you should also run', > clearly not 'this is absolutely essential' (because if it was, why wasn't it > done already or documented better?), which couldn't make it any clearer that > you need to think first why you might want to run that command. > > There are good reasons not to delete user accounts when removing the software > that uses them, for example, which is why pkg_delete doesn't but suggests > that you might want to (with copy pasta for your convenience). > > It's my responsibility to understand the software I'm running, how it works > and what effect the things I do will have on it. Nobody would have cried for > me if I'd pasted first and only then realised that I'd lost everything. > > Take responsibility for your own computers or stop using them and buy one of > those Fisher Price remote controlled radio-tracker remote execution vector > iToys that all the kids are playing with these days. > > Matthew > > ps. I do have backups of course. >
On blindly running code
With regards to recent discussion, here is a little anecdote that came out of the 6.5 to 6.6 upgrade. On one machine I run bitlbee, an IRC:IM gateway. After upgrading all the ports it left suggestions in the form of copy pasta commands to run to complete the upgrade process, as it does. One of these was rm -rf /var/bitlbee/*. Had I been so stupid as to just run the command, or if the hyper-complicated upgrade script required to support every possibility included a single mistake, all of the settings to connect to my IM accounts (currently constituting the only place some ancient passwords are guaranteed to be saved) would have been lost, where in fact what I had to do about those files was absolutely nothing. There is no fault here. The wording is something like 'you should also run', clearly not 'this is absolutely essential' (because if it was, why wasn't it done already or documented better?), which couldn't make it any clearer that you need to think first why you might want to run that command. There are good reasons not to delete user accounts when removing the software that uses them, for example, which is why pkg_delete doesn't but suggests that you might want to (with copy pasta for your convenience). It's my responsibility to understand the software I'm running, how it works and what effect the things I do will have on it. Nobody would have cried for me if I'd pasted first and only then realised that I'd lost everything. Take responsibility for your own computers or stop using them and buy one of those Fisher Price remote controlled radio-tracker remote execution vector iToys that all the kids are playing with these days. Matthew ps. I do have backups of course.
