OASIS Static Analysis Results Interchange Format (SARIF) TC

 View Only
  • 1.  RE: [sarif] More threadFlowLocation.kind values

    Posted 10-03-2018 21:03




    Hello all,
     
    Summarizing the discussion: Taking feedback from Michael and Yekaterina, I added these
    kind values:
     


    "entryPoint" : This location is an entry point to the application, device driver, service, or similar execution scope.
    "exitPoint" : This location is an exit point from the application, device driver, service, or similar execution scope.
    "branchFalse" : At this location, a branch in the execution path occurred because the branch condition evaluated to
    false .
    "branchTrue" : At this location, a branch in the execution path occurred because the branch condition evaluated to
    true .
    NOTE: Plain branch still exists.
    "endScope" : This location is the end of a variable scope (for example, a closing brace).
    "passthrough" : At this location, untrusted data was used without being sanitized.
    "exceptionFilter" : At this location, an exception filter was executed.
     
    Thanks,
    Larry
     


    From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
    On Behalf Of O'Neil, Yekaterina Tsipenyuk
    Sent: Wednesday, October 3, 2018 10:38 AM
    To: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>; 'O'Neil, Yekaterina Tsipenyuk' <katrina@microfocus.com>; Michael Fanning <Michael.Fanning@microsoft.com>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
    Subject: RE: [sarif] More threadFlowLocation.kind values


     
    Yes, passthrough and endScope would be useful to us. The former because we differentiate between just usage (e.g. variable was assigned null and then used, that is, dereferenced) and propagation of taint.
    The latter is useful for explaining why we report memory and resource leaks.
     
    As for lambda , it might be useful to separate it from just a call , but I guess not absolutely necessary.
     
    k
     


    From: Larry Golding (Myriad Consulting Inc) [ mailto:v-lgold@microsoft.com ]

    Sent: Tuesday, October 02, 2018 12:42 PM
    To: 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; Michael Fanning < Michael.Fanning@microsoft.com >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org >
    Subject: RE: [sarif] More threadFlowLocation.kind values


     
    Also, yes, as you noted, some results are purely informational (result.level == note ) or explicitly denote a success (result.level == pass ), so again sanitizer is useful.
     
    As for passthrough : we do have usage value, meaning at this location, data is used . But we can certainly consider adding taintedDataUsage if you would find it useful.
     
    We can also add endScope if you would find it useful.
     


    From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org >
    On Behalf Of Larry Golding (Comcast)
    Sent: Tuesday, October 2, 2018 9:04 AM
    To: 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; Michael Fanning < Michael.Fanning@microsoft.com >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org >
    Subject: RE: [sarif] More threadFlowLocation.kind values


     
    We changed our mind because (Paul or Michael, correct me if I am wrong) Grammatech needed a property that could guide their tool s UI to put icons in the margin indicating (for example), that a true branch was taken.
     
    You make an interesting point about sanitizer : presumably, if a datum passes through a sanitizer, it will not trigger a result for use of tainted data . But I can imagine a scenario where two pieces of tainted data enter the system and
    only one is sanitized


  • 2.  Re: [sarif] More threadFlowLocation.kind values

    Posted 10-03-2018 21:19
    I just added some comments of my own on issue #202: https://github.com/oasis-tcs/sarif-spec/issues/202 . A meta-question: should we continue this discussion by email thread or in the issue? -Paul On 10/3/2018 5:03 PM, Larry Golding (Myriad Consulting Inc) wrote: Hello all, Summarizing the discussion: Taking feedback from Michael and Yekaterina, I added these kind values: entryPoint : This location is an entry point to the application, device driver, service, or similar execution scope. exitPoint : This location is an exit point from the application, device driver, service, or similar execution scope. branchFalse : At this location, a branch in the execution path occurred because the branch condition evaluated to false . branchTrue : At this location, a branch in the execution path occurred because the branch condition evaluated to true . NOTE: Plain branch still exists. endScope : This location is the end of a variable scope (for example, a closing brace). passthrough : At this location, untrusted data was used without being sanitized. exceptionFilter : At this location, an exception filter was executed. Thanks, Larry From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of O'Neil, Yekaterina Tsipenyuk Sent: Wednesday, October 3, 2018 10:38 AM To: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com> ; 'O'Neil, Yekaterina Tsipenyuk' <katrina@microfocus.com> ; Michael Fanning <Michael.Fanning@microsoft.com> ; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org> Subject: RE: [sarif] More threadFlowLocation.kind values Yes, passthrough and endScope would be useful to us. The former because we differentiate between just usage (e.g. variable was assigned null and then used, that is, dereferenced) and propagation of taint. The latter is useful for explaining why we report memory and resource leaks. As for lambda , it might be useful to separate it from just a call , but I guess not absolutely necessary. k From: Larry Golding (Myriad Consulting Inc) [ mailto:v-lgold@microsoft.com ] Sent: Tuesday, October 02, 2018 12:42 PM To: 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; Michael Fanning < Michael.Fanning@microsoft.com >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] More threadFlowLocation.kind values Also, yes, as you noted, some results are purely informational (result.level == note ) or explicitly denote a success (result.level == pass ), so again sanitizer is useful. As for passthrough : we do have usage value, meaning at this location, data is used . But we can certainly consider adding taintedDataUsage if you would find it useful. We can also add endScope if you would find it useful. From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Comcast) Sent: Tuesday, October 2, 2018 9:04 AM To: 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; Michael Fanning < Michael.Fanning@microsoft.com >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] More threadFlowLocation.kind values We changed our mind because (Paul or Michael, correct me if I am wrong) Grammatech needed a property that could guide their tool s UI to put icons in the margin indicating (for example), that a true branch was taken. You make an interesting point about sanitizer : presumably, if a datum passes through a sanitizer, it will not trigger a result for use of tainted data . But I can imagine a scenario where two pieces of tainted data enter the system and only one is sanitized ð So I think the sanitizer kind could be useful. As for a call to lambda, I don t know. Is it semantically different from a function call? Larry From: O'Neil, Yekaterina Tsipenyuk < katrina@microfocus.com > Sent: Monday, October 1, 2018 5:28 PM To: Michael Fanning < Michael.Fanning@microsoft.com >; Larry Golding (Comcast) < larrygolding@comcast.net >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] More threadFlowLocation.kind values I was wondering in general why we changed our mind regarding the kind property (looks like I missed the discussion) if I recall correctly, at the face-to-face meeting we agreed not to use this property. Bu since we are working on the list, I am curious about why we have sanitizer kind on the list, considering it will probably not be part of any result (result won t be generated in this case). Or is the idea that it might be part of some informational result? On the other hand, why not add a passthrough kind to indicate that the taint was propagated at this location. Also, what about something like endScope to indicate the end of the variable scope? Finally, do we need a separate kind for lambda? k From: sarif@lists.oasis-open.org [ mailto:sarif@lists.oasis-open.org ] On Behalf Of Michael Fanning Sent: Monday, October 01, 2018 3:35 PM To: Larry Golding (Comcast) < larrygolding@comcast.net >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] More threadFlowLocation.kind values I d suggest making the first two concepts more generic. Entry points may occur at the driver or dynamic linked library level, for example, for some checkers. The following names might help make these a bit more general purpose entryPoint unloadOrExit terminate might be another option. From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Comcast) Sent: Monday, October 1, 2018 2:54 PM To: 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: [sarif] More threadFlowLocation.kind values Michael provided feedback on the change draft that restores threadFlowLocation.kind (Issues #194 and #202 , pushed from TC #24 to TC #25 for lack of time): Documents/ChangeDrafts/Active/sarif-v2.0-issues-194-202-threadFlowLocation-changes.docx He requested some additional values: applicationEntryPoint : This location is an entry point to the application. applicationExit : This location is a point of exit from the application. branchFalse : At this location, a branch in the execution path occurred because the branch condition evaluated to false . branchTrue : At this location, a branch in the execution path occurred because the branch condition evaluated to true . NOTE: Plain branch still exists. exceptionFilter : At this location, an exception filter was executed. Remember, the list is not meant to be exhaustive. The spec explicitly permits you to use any value you want if the defined values don t meet your needs. Thanks, Larry -- Paul Anderson, VP of Engineering, GrammaTech, Inc. 531 Esty St., Ithaca, NY 14850 Tel: +1 607 273-7340 x118; http://www.grammatech.com


  • 3.  RE: [sarif] More threadFlowLocation.kind values

    Posted 10-03-2018 21:22




    Let s continue it in the issue.
     


    From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
    On Behalf Of Paul Anderson
    Sent: Wednesday, October 3, 2018 2:19 PM
    To: sarif@lists.oasis-open.org
    Subject: Re: [sarif] More threadFlowLocation.kind values


     
    I just added some comments of my own on issue #202:
    https://github.com/oasis-tcs/sarif-spec/issues/202 .
    A meta-question: should we continue this discussion by email thread or in the issue?
    -Paul
     

    On 10/3/2018 5:03 PM, Larry Golding (Myriad Consulting Inc) wrote:


    Hello all,
     
    Summarizing the discussion: Taking feedback from Michael and Yekaterina, I added these
    kind values:
     


    "entryPoint" : This location is an entry point to the application, device driver, service, or similar execution scope.
    "exitPoint" : This location is an exit point from the application, device driver, service, or similar execution scope.
    "branchFalse" : At this location, a branch in the execution path occurred because the branch condition evaluated to
    false .
    "branchTrue" : At this location, a branch in the execution path occurred because the branch condition evaluated to
    true .
    NOTE: Plain branch still exists.
    "endScope" : This location is the end of a variable scope (for example, a closing brace).
    "passthrough" : At this location, untrusted data was used without being sanitized.
    "exceptionFilter" : At this location, an exception filter was executed.
     
    Thanks,
    Larry
     


    From: sarif@lists.oasis-open.org
    <sarif@lists.oasis-open.org> On Behalf Of
    O'Neil, Yekaterina Tsipenyuk
    Sent: Wednesday, October 3, 2018 10:38 AM
    To: Larry Golding (Myriad Consulting Inc)
    <v-lgold@microsoft.com> ; 'O'Neil, Yekaterina Tsipenyuk'
    <katrina@microfocus.com> ; Michael Fanning
    <Michael.Fanning@microsoft.com> ; 'OASIS SARIF TC Discussion List'
    <sarif@lists.oasis-open.org>
    Subject: RE: [sarif] More threadFlowLocation.kind values


     
    Yes, passthrough and endScope would be useful to us. The former because we differentiate between just usage (e.g. variable was assigned null and then used, that is, dereferenced) and propagation of taint.
    The latter is useful for explaining why we report memory and resource leaks.
     
    As for lambda , it might be useful to separate it from just a call , but I guess not absolutely necessary.
     
    k
     


    From: Larry Golding (Myriad Consulting Inc) [ mailto:v-lgold@microsoft.com ]

    Sent: Tuesday, October 02, 2018 12:42 PM
    To: 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; Michael Fanning < Michael.Fanning@microsoft.com >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org >
    Subject: RE: [sarif] More threadFlowLocation.kind values


     
    Also, yes, as you noted, some results are purely informational (result.level == note ) or explicitly denote a success (result.level == pass ), so again sanitizer is useful.
     
    As for passthrough : we do have usage value, meaning at this location, data is used . But we can certainly consider adding taintedDataUsage if you would find it useful.
     
    We can also add endScope if you would find it useful.
     


    From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org >
    On Behalf Of Larry Golding (Comcast)
    Sent: Tuesday, October 2, 2018 9:04 AM
    To: 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; Michael Fanning < Michael.Fanning@microsoft.com >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org >
    Subject: RE: [sarif] More threadFlowLocation.kind values


     
    We changed our mind because (Paul or Michael, correct me if I am wrong) Grammatech needed a property that could guide their tool s UI to put icons in the margin indicating (for example), that a true branch was taken.
     
    You make an interesting point about sanitizer : presumably, if a datum passes through a sanitizer, it will not trigger a result for use of tainted data . But I can imagine a scenario where two pieces of tainted data enter the system and
    only one is sanitized