Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:tail feathers from bird (Score 1) 54

And, incidentally, the same people are quoted in that article, also about amber from Myanmar.

Yeah, but no one reads the article :)

I used to write +5 moderated comments over and over, merely by reading the article, and restating some interesting points here in the comments. Easy mod points, and the mods hadn't read the article.

Comment Re:Well... (Score 1) 95

No, what he is referring to is that you get into a command shell, you can invoke an unsigned PowerShell script with PowerShell.exe -file. But that's not much different than source in bash.

But it's hard to imagine a social engineering attack that would get a user to download a file and then get them into a CLI session to override execute flags or signing to invoke the script file.

Comment Re:Not that big a leap (but I doubt OOP @ times) (Score 1) 95

This is one of the reasons micro kernels have a much more manageable security model. The problem being microkernels have some performance penalties that, at least in previous generations of CPUs, lead most OS developers to work in monolithic or mixed models. Yes, there are user space device drivers, so there has been a lot of work done to move device drivers a lot further away from Ring 0 and Ring 1, but even this simply makes monolithic kernels even more complex, and complexity is always the enemy of security.

Comment Re:(bash|sh|ksh|zsh) && !PowerShell (Score 1) 95

The kinds of vulnerabilities that PowerShell suffers would be suffered by any operating system that has a fairly comprehensive scripting language. The issue simply is if you can automate OS functions like creating, altering or deleting files and other system resources, someone can write a malicious script that, if run even in an non-super user context, can wreak havoc, but if run in a super user or similar higher access context can lead to enormous damage or to compromised systems. There are ways to mitigate this for both Windows and *nix, but more often than not you have to be proactive about it.

Comment Re:Microsoft Bash to the rescue (Score 1) 95

They're not, and suffer the same inherent vulnerability that Powershell or any other executable scripting language does; that even if you have core network and system resources ringfenced, malicious scripts can still play havoc with anything even regular users have access to (like shared file resources and the like).

The reality is, and this has been known for a couple of decades now, email and web clients simply should not be able to execute code. But since executable code, whether macros or scripts, show up in so many file formats it's all but impossible to fully enforce such a regime.

Comment Re: Now we have investment spam as news (Score 1) 247

"He's a firm believer in the underlying tech and the blockchain as a source of value in itself"

Hm, therein lies perhaps some of the difference between him and me. I was enamoured with the tech early but when I saw the problem of ever increasing blockchain sizes and the pretty much unsustainable quantity of bytes that needs to be shuffled around once the number of transactions increases to anything even approaching a globally accepted scale, and when I wrote a white paper proposing some mechanisms for mitigating this that went completely ignored by the bitcoin developers, I decided that the whole thing, while a great idea in principle, was going to collapse under the weight of the mostly intractible problem of bandwidth.

I still think it's not likely to succeed in the long term, but man was it a clever idea.

Comment Re:Replacing CMD (Score 3, Interesting) 95

Some of the nastier scripts out there nowadays aren't really about gaining elevated privileges. Some of them, like the encrypting ransomware requires no special privileges at all, but simply access to user files, and to network files that the user has read/write access to. So while the critical aspects of a computer or a network are protected by execution and system resource access limitations, you need to prevent execution of unauthorized scripts completely.

I have to admit I've found signing Powershell scripts to be a mighty pain in the arse, but it does provide some protection against external scripts running when you maintain the blocking of execution of unsigned scripts. It isn't a complete protection, unfortunately, and Powershell is only one route by which this kind of ransomware could end up on a system. Vulnerabilities in Java, MS-Office files, and even the execution of Windows Scripting Host files (vbscript and jscript) seem more common from my experience.

The one bit of ransomware I saw got loose through a vbscript file attached to an email. For whatever reason, Outlook allowed it to be executed, and the user clicked the dialog that might have prevented it, and then the script went to town encrypting files on the user's own folders and the share. Fortunately there's a good backup regime in place, so there was very little actual loss, but it demonstrated that along with some vulnerabilities in Windows' execution protection schemes, the real weak link as always is users themselves.

Slashdot Top Deals

A rolling disk gathers no MOS.

Working...