pytm
pytm copied to clipboard
izar
DO02 - huh?
"DO02": { "description": "Potential Process Crash or Stop", "source": (Process, Datastore, Element), "target": Process, "condition": "target.handlesCrashes is False", },
What is the thought process behind this threat? Is it that the Process can crash, or that it could crash in some security-relevant way? It would seem to me that if the concern is that a Process may crash, then the conditions one might check for would be susceptibility to a buffer overflow in unmanaged code, not whether or not it can "handle" crashes, whatever that means...
yep - i think this might be a "migration" from the MSFT tool repertoire. I think the stress is on the handlesCrashes value - as in "your process should be able to handle crashes gracefully". Perhaps the description should better reflect that.
In a Process, if it knows how to clean up (no core files, no temporary files, perhaps restarts after crash) , notifies and logs crash?
Or if it handles all exceptions?
On Tue, Oct 30, 2018, 14:46 Izar Tarandach [email protected] wrote:
In a Process, if it knows how to clean up (no core files, no temporary files, perhaps restarts after crash) , notifies and logs crash?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/izar/pytm/issues/31#issuecomment-434420545, or mute the thread https://github.com/notifications/unsubscribe-auth/AlkM-iJq5EgLAnUS9GpvRMC_X4-08EKRks5uqJ6FgaJpZM4XyhAl .
--
-- Matt Coles
It may be time to introduce some logic into the attributes?
obj.handlesExceptions = True +
obj.cleansUp = True | ==> obj.handlesCrashes = True
obj.restartsAfterCrash = True +
This threat is targeted more towards those applications that reveal stack traces when something goes wrong etc. I'm on the keeping it simple side for the threats as I'm afraid adding logic into attributes may raise the complexity and entry barrier for folks adopting pytm. What do you think?
I don't know, I see it as a logical progression - as in beginners can keep it simple but more advanced users may use the logic if they need.
Either way it sounds like there is enough confusion that this threats needs an edit, or split into 2 - handles crashes, and exposes sensitive data on error. Adding metadata such as the CWE would be useful here.
On Tue, Oct 30, 2018, 18:40 Izar Tarandach [email protected] wrote:
I don't know, I see it as a logical progression - as in beginners can keep it simple but more advanced users may use the logic if they need.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/izar/pytm/issues/31#issuecomment-434495908, or mute the thread https://github.com/notifications/unsubscribe-auth/AlkM-vAJbW-bkBBdbD9ZZutODufF5vF8ks5uqNVUgaJpZM4XyhAl .
--
-- Matt Coles
Just a reply to Rohit on complexity and barrier to entry - threats and condition logic can be complex without impacting the users who want to keep things simple in how they describe the objects analyzed for threats. Making the objects "flat" in their properties enables this, with perhaps limits on what can be determined.
On Tue, Oct 30, 2018, 18:51 Izar Tarandach [email protected] wrote:
PRs! We need PRs! 😄
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/izar/pytm/issues/31#issuecomment-434498538, or mute the thread https://github.com/notifications/unsubscribe-auth/AlkM-ujDdZ1KafAUfWfAs8ojtz0E45fUks5uqNfhgaJpZM4XyhAl .
--
-- Matt Coles
Cool, sounds good!
I'll update this threat since I'm working on creating a schema for the threats.
Just to make sure, I'll update the condition for this threat as: are you handling process crashes gracefully and/or are you revealing sensitive info on crash. Ok?
Might be best to split into 2 as I suggested earlier. A process that handles a crash may still expose data, and a process that avoids exposing data on crash may not handle the crash properly; they lead to different weaknesses.
On Tue, Oct 30, 2018, 19:00 Rohit Shambhuni [email protected] wrote:
Cool, sounds good!
I'll update this threat since I'm working on creating a schema for the threats.
Just to make sure, I'll update the condition for this threat as: are you handling process crashes gracefully and/or are you revealing sensitive info on crash. Ok?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/izar/pytm/issues/31#issuecomment-434500857, or mute the thread https://github.com/notifications/unsubscribe-auth/AlkM-qA8Y3N-hZa79KjvMAOBumw8FLY4ks5uqNnxgaJpZM4XyhAl .
--
-- Matt Coles
Looks like this issue is not valid anymore, this threat has been repurposed and handleCrashes prop is now unused. Can we close this?
