OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sarif] RE: IANA media type registration


Thanks Michael. I pushed the changes to IANA media type registration form.txt in our repo.

 

Everyone else, this is still open for discussion until we send the registration request (or even after, I suppose).

 

Larry

 

From: Michael Fanning <Michael.Fanning@microsoft.com>
Sent: Thursday, June 28, 2018 9:31 AM
To: Larry Golding (Comcast) <larrygolding@comcast.net>; 'O'Neil, Yekaterina Tsipenyuk' <katrina@microfocus.com>; 'Luke Cartey' <luke@semmle.com>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: RE: [sarif] RE: IANA media type registration

 

Agreed on all this. Just want to restate: this guidance is thorough, extremely clear and suited to purpose. Nice work.

 

From: Larry Golding (Comcast) <larrygolding@comcast.net>
Sent: Wednesday, June 27, 2018 4:50 PM
To: Michael Fanning <Michael.Fanning@microsoft.com>; 'O'Neil, Yekaterina Tsipenyuk' <katrina@microfocus.com>; 'Luke Cartey' <luke@semmle.com>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: RE: [sarif] RE: IANA media type registration

 

Inline

 

-- Larry

 

From: Michael Fanning <Michael.Fanning@microsoft.com>
Sent: Wednesday, June 27, 2018 3:25 PM
To: Larry Golding (Comcast) <larrygolding@comcast.net>; 'O'Neil, Yekaterina Tsipenyuk' <katrina@microfocus.com>; 'Luke Cartey' <luke@semmle.com>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: RE: [sarif] RE: IANA media type registration

 

This is improved, thank you.

 

  1. We deferred an issue around provide mechanisms within SARIF for signing/encrypting data in preference of external mechanisms. Why wouldn’t we cite this as a useful approach? You mention using HTTPS, that’s no different in mind (i.e., it provides a concrete example of a technology that might protect SARIF that contains sensitive info). On the other hand, if the industry can’t decide on a standard/leading JSON payload encryption/signing standard, may not be worth mentioning. All things considered, maybe we just drop the point.
    [Larry] Yes, that was my thought: since there wasn’t a well-accepted way to do this, we may as well not mention it.
  2. This sentence makes me nervous. I don’t think we should even float the idea that a SARIF consumer would expand some executable content from the log file and execute it. This is a very bad idea. Let’s not even float it is my suggestion. Let’s leave the SHOULD guidance on producers not emitting this data.
    [Larry] I think what you’re saying is that you’d like my Item #7 to read something like this:

 

7) SARIF defines an extensibility mechanism that allows SARIF producers to include arbitrary

                properties in a SARIF file (information that is not explicitly defined in the SARIF format).

                SARIF producers should not use this mechanism to define properties that contain executable code or

                script.

Right?

 

 

From: Larry Golding (Comcast) <larrygolding@comcast.net>
Sent: Wednesday, June 27, 2018 10:01 AM
To: Michael Fanning <Michael.Fanning@microsoft.com>; 'O'Neil, Yekaterina Tsipenyuk' <katrina@microfocus.com>; 'Luke Cartey' <luke@semmle.com>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: RE: [sarif] RE: IANA media type registration

 

Point taken. I agree that repeating the “appropriate security” mantra over and over is a bit much.

 

However, we do need to mention it. In RFC 6838, “Media Type Specifications and Registration Procedures,” Section 4.6, “Security Considerations,” it says:

 

      A media type might be targeted for applications that require some

      sort of security assurance but don't provide the necessary

      security mechanisms themselves.  For example, a media type could

      be defined for storage of sensitive medical information that in

      turn requires external confidentiality and integrity protection

      services, or which is designed for use only within a secure

      environment.  Types SHOULD always document whether or not they

      need such services in their security considerations.

 

(NOTE: How is “SHOULD always” different from “SHALL”? 😉)

 

Our media type is “targeted for applications that require some sort of security assurance”, similar to the “medical information” application they cite. It is not a generic format like a text file or human speech. For that reason I don’t entirely agree with your statement “The issue is the data, not the format.” Our format is designed to hold certain types of data which are often sensitive.

 

I’d like to punt on mentioning cryptographically signed JSON for now. We had an issue for it but deferred it.

 

How about this:

 

Security considerations:

 

Producers and consumers of SARIF files should consider the following security-related issues.

Some of these issues arise from the fact that SARIF files contain potentially sensitive information

about software and software development environments. Since SARIF is a textual format with

no provision for protecting sensitive information, SARIF should only be used in an environment

that provides an appropriate level of security. For example, SARIF files might be stored on a

file share with limited permissions, or transmitted by means of an encrypted protocol such as HTTPS.

 

               1) SARIF files contain results produced by static analysis tools. These results might

               describe security vulnerabilities, or other defects that should not be disclosed, in the

               software being analyzed. Since SARIF is a textual format with no provision for protecting

               potentially sensitive results, SARIF should only be used in an environment that provides an

               appropriate level of security. For example, SARIF files might be stored on a file share with

               limited permissions, or transmitted by means of an encrypted protocol such as HTTPS.

 

               2) SARIF files contain URIs which specify the location of the files that were analyzed.

               If these URIs are absolute, they might disclose information about the system on which the

               analysis took place, such as the name of the engineer, for example: "file://C:/Users/MarySmith/src/ui/window.c".

               For this reason, URIs should be specified as relative references, for example: "ui/window.c".

 

                Even relative URIs might disclose sensitive information about the implementation of the software,

                for example, "encryption/sha1.c". For this reason, again, SARIF should only be used in an

                environment that provides sufficient security.

 

                3) SARIF provides a property run.originalBaseUriIds whose purpose is explicitly to provide the

                absolute URI ("file:/Users/MarySmith") with respect to which relative references such as

                "ui/window.c" are evaluated. This property might disclose sensitive information, and should only be used

                in an environment that provides sufficient security.

 

                4) SARIF provides an object named invocation which contains information about how the static

                analysis tool was invoked. Many of its properties (for example, machine, account, and

                environmentVariables) disclose information about the machine on which the analysis took

                place. These properties should only be used in an environment that provides sufficient

                security.

 

                5) The URIs in a SARIF file might point to insecure resources such as malicious web sites.

                They might also contain executable code (for example, in a "_javascript_:" URI). SARIF

                producers should not emit such URIs. SARIF consumers should take care not to follow

                malicious links. In practice, this means that end users should not open SARIF files

                unless they trust the producer.

 

                6) User-visible messages in SARIF files can be expressed either in plain text or in a rich

                text format (by default, GitHub-flavored Markdown). Markdown can contain arbitrary HTML,

                which poses a security risk. SARIF producers should not emit HTML. SARIF consumers should

                sanitize the Markdown they receive (for example, by removing embedded HTML). SARIF consumers

                should process Markdown with a Markdown processor that allows HTML processing to be disabled,

                and that guards against stack overflows induced by maliciously constructed Markdown.

 

                7) SARIF defines an extensibility mechanism that allows SARIF producers to include arbitrary

                properties in a SARIF file (information that is not explicitly defined in the SARIF format).

                If a SARIF producer uses this mechanism to define a property that contains executable code or

                script, and if SARIF consumer that is aware of this property executes the content, this might

                permit an attack. SARIF producers should not emit executable content. If they do, a SARIF

                consumer that is aware of that content should execute it only if it trusts the producer.

 

 

From: Michael Fanning <Michael.Fanning@microsoft.com>
Sent: Wednesday, June 27, 2018 9:34 AM
To: O'Neil, Yekaterina Tsipenyuk <katrina@microfocus.com>; Larry Golding (Comcast) <larrygolding@comcast.net>; Luke Cartey <luke@semmle.com>; David Keaton <dmk@dmk.com>; Mr. Stefan Hagen <stefan@hagen.link>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: RE: [sarif] RE: IANA media type registration

 

This list is pretty comprehensive but also tends a bit towards being scary. I wonder whether we could try to adjust the language to provide more nuance on security concerns being related to the purpose to which the format is put. Make sense? JSON obviously provides a natural mechanism for persisting a URI. Now consider making this statement:

 

“For this reason, again, JSON should only be used in an environment that provides sufficient security.”

 

A text file can contain a clear text password. Consider this statement:

 

“For this reason, again, text files should only be used in an environment that provides sufficient security.”

 

Does my point make sense? Any format is a mechanism for transmitting information that may be insecure. It is most helpful in your guidance to clearly articulate particular places where someone may reasonably transmit data that leads to security problems. The data is the issue, not the format. The security approach depends on the data that you are transmitting, not, strictly, the format.

 

Can’t resist this: you can say your password aloud and it may be overheard:

 

“For this reason, again, human speech should only be used in an environment that provides sufficient security.”

 

😊

 

Final suggestion: there are mechanisms out there for cryptographic signing of JSON and it may be useful to point out that these exist. Last time I looked at the situation (I am not particularly knowledgeable here), there didn’t seem to be a clearly accepted approach…

From: O'Neil, Yekaterina Tsipenyuk <katrina@microfocus.com>
Sent: Monday, June 25, 2018 10:41 PM
To: Larry Golding (Comcast) <larrygolding@comcast.net>; Luke Cartey <luke@semmle.com>; Michael Fanning <Michael.Fanning@microsoft.com>; David Keaton <dmk@dmk.com>; Mr. Stefan Hagen <stefan@hagen.link>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: RE: [sarif] RE: IANA media type registration

 

Looks good to me!

k

 

From: sarif@lists.oasis-open.org [mailto:sarif@lists.oasis-open.org] On Behalf Of Larry Golding (Comcast)
Sent: Monday, June 25, 2018 3:15 PM
To: Luke Cartey <luke@semmle.com>; Michael Fanning <Michael.Fanning@microsoft.com>; David Keaton <dmk@dmk.com>; Mr. Stefan Hagen <stefan@hagen.link>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: [sarif] RE: IANA media type registration
Importance: High

 

Hello all,

 

I wrote the “Security Considerations” section for our IANA media type registration. For your convenience, I reproduce it here. Please comment!

 

Security considerations:

 

                Producers and consumers of SARIF files should consider the following security-related issues:

 

                1) SARIF files contain results produced by static analysis tools. These results might

                describe security vulnerabilities, or other defects that should not be disclosed, in the

                software being analyzed. Since SARIF is a textual format with no provision for protecting

                potentially sensitive results, SARIF should only be used in an environment that provides an

                appropriate level of security. For example, SARIF files might be stored on a file share with

                limited permissions, or transmitted by means of an encrypted protocol such as HTTPS.

 

                2) SARIF files contain URIs which specify the location of the files that were analyzed.

                If these URIs are absolute, they might disclose information about the system on which the

                analysis took place, such as the name of the engineer, for example: "file://C:/Users/MarySmith/src/ui/window.c".

                For this reason, URIs should be specified as relative references, for example: "ui/window.c".

 

                Even relative URIs might disclose sensitive information about the implementation of the software,

                for example, "encryption/sha1.c". For this reason, again, SARIF should only be used in an

                environment that provides sufficient security.

 

                3) SARIF provides a property run.originalBaseUriIds whose purpose is explicitly to provide the

                absolute URI ("file:/Users/MarySmith") with respect to which relative references such as

                "ui/window.c" are evaluated. This property discloses information, and should only be used

                in an environment that provides sufficient security.

 

                4) SARIF provides an object named invocation which contains information about how the static

                analysis tool was invoked. Many of its properties (for example, machine, account, and

                environmentVariables) disclose information about the machine on which the analysis took

                place. These properties should only be used in an environment that provides sufficient

                security.

 

                5) The URIs in a SARIF file might point to insecure resources such as malicious web sites.

                They might also contain executable code (for example, in a "_javascript_:" URI). SARIF

                producers should not emit such URIs. SARIF consumers should take care not to follow

                malicious links. In practice, this means that end users should not open SARIF files

                unless they trust the producer.

 

                6) User-visible messages in SARIF files can be expressed either in plain text or in a rich

                text format (by default, GitHub-flavored Markdown). Markdown can contain arbitrary HTML,

                which poses a security risk. SARIF producers should not emit HTML. SARIF consumers should

                sanitize the Markdown they receive (for example, by removing embedded HTML). SARIF consumers

                should process Markdown with a Markdown processor that allows HTML processing to be disabled,

                and that guards against stack overflows induced by maliciously constructed Markdown.

 

                7) SARIF defines an extensibility mechanism that allows SARIF producers to include arbitrary

                properties in a SARIF file (information that is not explicitly defined in the SARIF format).

                If a SARIF producer uses this mechanism to define a property that contains executable code or

                script, and if SARIF consumer that is aware of this property executes the content, this might

                permit an attack. SARIF producers should not emit executable content. If they do, a SARIF

                consumer that is aware of that content should execute it only if it trusts the producer.

 

 

Thanks,

Larry

 

From: Larry Golding (Comcast) <larrygolding@comcast.net>
Sent: Monday, June 25, 2018 2:28 PM
To: Luke Cartey <luke@semmle.com>; Michael Fanning <Michael.Fanning@microsoft.com>; David Keaton <dmk@dmk.com>; Mr. Stefan Hagen <stefan@hagen.link>
Cc: 'Robin Cover' <robin@oasis-open.org>
Subject: IANA media type registration

 

Hi Luke,

 

IIRC, you are going to handle the IANA media type registration. As I mentioned a few days ago, I’m going to provide the “Security considerations” section. I’m now ready to do that.

 

For convenience in collaborating on this registration, I created a document IANA media type registration form.txt in our repo’s Documents folder. I filled in a few fields, and will now add the Security section.

 

It’s plain text to make it easier to paste it into IANA’s Application for a media type web form when we’re ready.

 

Thanks,

Larry



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]