http://permalink.gmane.org/gmane.comp.mozilla.security hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.mozilla.security/5375 <pre>Mailman was down yesterday and some of the lists didn't come back. If you're seeing this mail then dev-security is working. -Dan Veditz </pre> Daniel Veditz 2012-05-16T18:34:51 http://permalink.gmane.org/gmane.comp.mozilla.security/5373 <pre>I have firefox working with CAC smartcard auth via the coolkey module and/or cackey.. The only problem is that when accessing a secure site firefox is not prompting me to select a certificate even though I have "ask every time" selected. The smartcard has two certs on it. Verified that both libcackey.so and libcoolkeypk11.so modules see both certificates outside of firefox. When I try via IE it prompts me to select a cert. Anyone have any ideas? Thanks, Crue </pre> cruejones< at >comcast.net 2012-05-14T17:37:33 http://permalink.gmane.org/gmane.comp.mozilla.security/5372 <pre>I've started a project to produce an experimental browser (Flowerbeetle) and an experimental e-mail client (Flowerduck). The purpose is to enable early testing of security and PKI related changes, which are proposed for the Mozilla platform (including Firefox and Thunderbird), but which haven't yet been fully reviewed and accepted for inclusion. Just to make it clear, this isn't an official Mozilla.org project, it's (currently) my own initiative. If you're interested in testing and giving feedback, please visit https://kuix.de/flowerbeetle and https://kuix.de/flowerduck for more information. For the full list of experimental changes included, please visit the download pages. Notable changes are: - support for OCSP stapling and the OCSP HTTP GET mechanism - disable acceptance of MD5 in signatures - use of the smarter libPKIX certificate verification engine (which unfortunately still has some stability bugs and would benefit from contributions to improve it) - libPKIX allows for automatic downlo</pre> Kai Engert 2012-05-11T15:53:03 http://permalink.gmane.org/gmane.comp.mozilla.security/5371 <pre>(sorry, wrong subject) </pre> Paul Theriault 2012-05-10T17:09:21 http://permalink.gmane.org/gmane.comp.mozilla.security/5370 <pre>(Please reply-to dev-webapps&lt; at &gt;lists.mozilla.org) Name of API: Alarm API Reference: https://groups.google.com/d/topic/mozilla.dev.webapi/pkx1uz_pnhQ/discussion Brief purpose of API: General Use Cases:Add an alarm (relaunch the app via alarm intentat a future time) Inherent threats:Annoyance Threat severity: Low == Regular web content (unauthenticated) == Use cases for unauthenticated code: Relaunch the app via an alarm intent at a future time Authorization model for normal content: None Authorization model for installed content: Implicit Potential mitigations: Should be a way to disable alarm for a given app == Trusted (authenticated by publisher) == Same as for installed untrusted app == Certified (vouched for by trusted 3rd party) == Same as for installed untrusted app </pre> Paul Theriault 2012-05-10T17:06:17 http://permalink.gmane.org/gmane.comp.mozilla.security/5368 <pre>(Please reply-to dev-webapps&lt; at &gt;lists.mozilla.org) Name of API: Battery API Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=678694 http://dvcs.w3.org/hg/dap/raw-file/tip/battery/Overview.html Note from spec: The API defined in this specification is used to determine the battery status of the hosting device. The information disclosed has minimal impact on privacy or fingerprinting, and therefore is exposed without permission grants. For example, authors cannot directly know if there is a battery or not in the hosting device. Brief purpose of API: General Use Cases:Adjust app behavior based upon power status Inherent threats:Fingerprinting, abuse of battery? Threat severity:low == Regular web content (unauthenticated) == Use cases:Same Authorization model for normal content: Implicit Authorization model for installed content: Implicit Potential mitigations: None == Trusted (authenticated by publisher) == Use cases:Same Authorization mode: Implicit Potential mitigations:None == Certified (vou</pre> Paul Theriault 2012-05-09T19:02:49 http://permalink.gmane.org/gmane.comp.mozilla.security/5367 <pre>(Please reply-to dev-webapps&lt; at &gt;lists.mozilla.org) Name of API: Network Information API Sec Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=677166 https://wiki.mozilla.org/WebAPI/NetworkAPI Brief purpose of API: General Use Cases: Read current bandwidth estimate or ask if connection is metered Listen for connection change events Inherent threats: Privacy (de-anonymize users based on connection change events?) Threat severity:Low == Regular web content (unauthenticated) == Use cases for unauthenticated code: Read current bandwidth estimate or ask if connection is metered Authorization model for normal content: Read current bandwidth estimate or ask if connection is metered Authorization model for installed content: Potential mitigations: Maybe fuzz the exact time of the network change event in a similar manner to idle API. == Trusted (authenticated by publisher) == Use cases for authenticated code:As above Use cases for trusted code: Potential mitigations: == Certified (vouched for by truste</pre> Paul Theriault 2012-05-09T18:57:27 http://permalink.gmane.org/gmane.comp.mozilla.security/5366 <pre>Please reply-to dev-webapps&lt; at &gt;lists.mozilla.org Name of API: Web Bluetooth API Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=674737 https://wiki.mozilla.org/WebAPI/WebBluetooth Brief purpose of API: The aim of WebBluetooth is to establish a DOM API to set up and communicate with Bluetooth devices. This includes setting properties on adapters and devices, scanning for devices, bonding, and socket initialization for audio and communication. General Use Cases: Inherent threats: Privacy, access to sensitive user devices, de-anonimization based on bluetooth state Threat severity: high == Regular web content (unauthenticated) == Use cases: None Authorization model for normal content: None Authorization model for installed content: None Potential mitigations: == Trusted (authenticated by publisher) == Use cases: None Authorization model: None Potential mitigations: == Certified (vouched for by trusted 3rd party) == Use cases: Read bluetooth adapter state Start/Stop device discovery List disco</pre> Lucas Adamski 2012-05-09T18:31:31 http://permalink.gmane.org/gmane.comp.mozilla.security/5365 <pre>Please reply-to dev-webapps&lt; at &gt;lists.mozilla.org Name of API: Keyboard API Reference: See: https://groups.google.com/d/topic/mozilla.dev.webapi/Vs3-HGv9NNw/discussion Brief purpose of API: Allow virtual keyboard to be implemented as a Web App General Use Cases: *Replace the installed keyboard with a different one *Choose what keyboard is shown (numeric, alphanumeric, symbols, first letter capiltaized etc) Inherent threats: Access to user keystrokes (steal passwords, bank account details, etc), send trusted key events Threat severity: high == Regular web content (unauthenticated) == Use cases for unauthenticated code: Request which keyboard [type?] is displayed Authorization model for uninstalled web content: implicit for focused top-level content Authorization model for installed web content: implicit Potential mitigations: Request keyboard [type] only. == Trusted (authenticated by publisher) == Use cases for authenticated code: Implement new keyboard. Authorization model: Implicit Potential mitigation</pre> Lucas Adamski 2012-05-09T18:17:54 http://permalink.gmane.org/gmane.comp.mozilla.security/5364 <pre>(Please reply-to dev-webapps&lt; at &gt;lists.mozilla.org) Name of API: Background API Reference: http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/3455cb056e40d095 Related: Brief purpose of API: Provide for applications to request to remain and run in the background. It is not intended for pure background services. General Use Cases:Use cases: Navigation app continuing to run and provide driving prompts from the background. Inherent threats: Resource utilization Threat severity: Low by itself. Could raise the security concerns of other APIs. == Regular web content (unauthenticated) == Use cases for unauthenticated code: Streaming radio station wants to continue to play in the background. Authorization model for normal content: Implicit Authorization model for installed content: Implicit Potential mitigations: == Trusted (authenticated by publisher) == Use cases for authenticated code:Implicit Use cases for trusted code:Implicit Potential mitigations: == Certified (vouched for by </pre> Paul Theriault 2012-05-08T23:59:58 http://permalink.gmane.org/gmane.comp.mozilla.security/5363 <pre>Please reply-to dev-webapps&lt; at &gt;lists.mozilla.org Name of API: Permission API Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=707625 Brief purpose of API: Allow an app to manage app permissions in a centralized location General Use Cases: None Inherent threats: Change security and privacy permissions, potentially leading to device compromise Threat severity: Critical == Regular web content (unauthenticated) == Use cases for unauthenticated code:None Authorization model for normal content: None Authorization model for installed content: None Potential mitigations: == Trusted (authenticated by publisher) == Use cases for authenticated code: None Use cases for trusted code: None Potential mitigations: == Certified (vouched for by trusted 3rd party) == Use cases for certified code: Centralized permissions management app; modify per-app settings Authorization model: Implicit Potential mitigations: None Note: We are not exposing permission settings to non-certified apps. Apps cannot determine thei</pre> Lucas Adamski 2012-05-08T23:47:47 http://permalink.gmane.org/gmane.comp.mozilla.security/5362 <pre>Please reply-to dev-webapps&lt; at &gt;lists.mozilla.org Name of API: Device Storage Reference: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI Brief purpose of API: Let content access files based on name and type. Can be enumerated. Inherent threats: Use excessive resources (file space), read files, change or delete files. Files could potentially contain confidential information. Threat severity: high to critical - privacy concerns, loss of user data, access to confidential data. == Regular web content (unauthenticated) == Use cases for unauthenticated code: Access a previously taken profile picture, select a song to play. Authorization model for uninstalled web content: Explicit (OS Mediated) Authorization model for installed web content: Explicit (OS Mediated) Potential mitigations: Make sure the user knows what files is being accessed when asking permission. No option to remember permission. OS mediated interface (like file picker - via intents?). == Trusted (authenticated by publisher) == Use cas</pre> Paul Theriault 2012-05-08T22:59:49 http://permalink.gmane.org/gmane.comp.mozilla.security/5361 <pre>Please reply-todev-webapps&lt; at &gt;lists.mozilla.org Name of API: Wifi API Reference: http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/ed980c42261c5f4a?pli=1 Brief purpose of API: Detect and connect to wifi networks, to support a wifi management app. General Use Cases: None Inherent threats: Privacy(identify user, geolocation, based on wifi characteristics), Denial of Service, Unexpected or unauthorized network connections (e.g. connect to home wifi network ?) Threat severity: High == Regular web content (unauthenticated) == Use cases for unauthenticated code:None Authorization model for normal content: Authorization model for installed content: Potential mitigations: == Trusted (authenticated by publisher) == Use cases for authenticated code: * Wifi sniffer app * Wifi provider connection app (e.g. connect to provider X hotspots with authentication credentials) Use cases for trusted code: Explicit Potential mitigations: == Certified (vouched for by trusted 3rd party) == Use cases</pre> Paul Theriault 2012-05-08T21:24:31 http://permalink.gmane.org/gmane.comp.mozilla.security/5360 <pre>Please reply-to dev-webapps&lt; at &gt;lists.mozilla.org Name of API: Socket API Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=733573 Brief purpose of API: Grant full access to raw sockets to allow applications such as SMTP clients etc General Use Cases: None Inherent threats:Malicious apps attacking internal systems (firewall bypass), local device access Threat severity: High == Regular web content (unauthenticated) == Use cases for unauthenticated code:None Authorization model for normal content: Authorization model for installed content: Potential mitigations: == Trusted (authenticated by publisher) == Use cases for authenticated code: Talk to non-HTTP services. SSH, FTP, mail clients, supporting custom protocols Use cases for trusted code: Implicit Potential mitigations: Firewall should prohibit access to privileged low number OS ports (&lt;1024). Listening on a port &lt; 1024 should be prohibited. == Certified (vouched for by trusted 3rd party) == Use cases for certified code: Open a connection t</pre> Lucas Adamski 2012-05-08T18:50:15 http://permalink.gmane.org/gmane.comp.mozilla.security/5359 <pre>Please reply-to dev-webapps&lt; at &gt;lists.mozilla.org Name of API: Sensor API Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=697361 http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/ Brief purpose of API: Let apps access environmental sensor data gathered by devices. General Use Cases: None Inherent threats:Privacy Threat severity: Moderate == Regular web content (unauthenticated) == Use cases for unauthenticated code: Monitor environmental sensor data like temperature, barometer, magnetic field, Authorization model for normal content: Explicit Authorization model for installed content: Implicit Potential mitigations: Only available to top-level content while focused == Trusted (authenticated by publisher) == Use cases for authenticated code: Same Use cases for trusted code: Implicit Potential mitigations: == Certified (vouched for by trusted 3rd party) == Use cases for certified code: Backlight Dimming based on ambient light Screen-off based on proximity Authorization model: Implicit Potential </pre> Lucas Adamski 2012-05-08T18:41:46 http://permalink.gmane.org/gmane.comp.mozilla.security/5358 <pre>Please reply-to dev-webapps&lt; at &gt;lists.mozilla.org Name of API: Mobile Connection API Reference: https://wiki.mozilla.org/WebAPI/WebMobileConnection Brief purpose of API: This exposes information about the current mobile voice and data connection to (certain) HTML content. Use Cases: The primary use case for this is the status bar of the main phone UI. Inherent threats: Access to sensitive information such as: ICC-related (SIM/RUIM card) own phone number and other ICC I/O related features entering PIN, PIN2, PUK, PUK2 to unlock various states of the SIM card. Entering the PIN isn't *that* exotic, actually. Some carriers deliver their SIM cards with the PIN lock enabled, for instance. changing the PIN (also serves as enabling/disabling the PIN lock.) device-related get IMEI, IMEISV depersonalize (remove network lock) baseband-related information and features Threat severity: High == Regular web content (unauthenticated) == Use cases for unauthenticated code: None Authorization mode</pre> Lucas Adamski 2012-05-07T20:35:42 http://permalink.gmane.org/gmane.comp.mozilla.security/5357 <pre>I have posted an update to the app security model to https://wiki.mozilla.org/Apps/Security The previous discussion that was located there has been moved to https://wiki.mozilla.org/Apps/Security/Discussion </pre> Lucas Adamski 2012-05-07T19:35:38 http://permalink.gmane.org/gmane.comp.mozilla.security/5356 <pre> ----- Original Message ----- From: "Jonas Sicking" &lt;jonas&lt; at &gt;sicking.cc&gt; To: "Adrienne Porter Felt" &lt;apf&lt; at &gt;berkeley.edu&gt; Cc: dev-webapps&lt; at &gt;lists.mozilla.org, dev-webapi&lt; at &gt;lists.mozilla.org, dev-security&lt; at &gt;lists.mozilla.org, "Lucas Adamski" &lt;ladamski&lt; at &gt;mozilla.com&gt;, "dev-b2g mailing list" &lt;dev-b2g&lt; at &gt;lists.mozilla.org&gt; Sent: Thursday, May 3, 2012 4:05:38 AM Subject: Re: [b2g] WebAPI Security Discussion: Vibration API when working on a previous user agent, when pitching what is essentially the sandbox attribute's 'allow-same-origin' functionality to various people, a common request that came up was 'site authors want a way to stop hosted, possibly user generated, content being annoying' so, FWIW i'm in favor of exploring extending the sandbox attribute to deal with cases like restricting vibration or audio - the existing 'sandboxing automatic features' flag which is set if 'allow-scripts' isn't specified is a start along these lines already and has a somewhat 'up to the reader' interpretation beyond the mentioned example</pre> Ian Melven 2012-05-07T16:35:50 http://permalink.gmane.org/gmane.comp.mozilla.security/5355 <pre>In general, I'd buy that permission prompts are deferred until an app comes into focus. Once the permission has been granted or denied, that is going to be sticky, so the app can keep using it in the background. I'm not sure we want to deny access to an API for which permission has been granted when an app is not the focus. Certainly not for every API. I'll have to review the API list to see if there are any that might need that treatment. If there are, we should add it to the API review template. As for services, these might be things like an alternate keyboard that want access to APIs. There is no specific app for the alternate keyboards (I think the idea at the moment is that these services would have special tagging in the manifest, or register themselves when first installed). The services is invoked by an intent. At that point (at least for input) it does have a displayed component. As an example, a keyboard service may want access to an API (ok, these are a little bit of a stretch, but a key</pre> Jim Straus 2012-05-04T21:14:48 http://permalink.gmane.org/gmane.comp.mozilla.security/5354 <pre> That's an interesting question. Could another approach be that the app needs to have focus to obtain the permissions, and that permission is blocked until it becomes foreground? I think a lot of the permissions really need apps to be focused before they can be granted anyway per our notification model. Its a pretty complicated problem though, depending on if you think of these as apps, or as services. Lucas. </pre> Lucas Adamski 2012-05-04T18:36:05 http://permalink.gmane.org/gmane.comp.mozilla.security/5353 <pre> I feel like vibration is very similar to audio. I'm fairly sure there are websites that have a policy that none of the ads that they are showing are allowed to play audio. Unfortunately this can't be enforced through technical means right now, with the result being that sometimes ad agencies break the policies. I see the desire to disable vibration for cross-origin iframes, but I think it would also disable useful usecases if we do it as a blanket policy. For example many games on facebook run inside an iframe. What would be really cool is if we had the ability for a site to create an iframe for an ad and say that the contents of the iframe wasn't allowed to play audio or enable the vibrator. Alternatively we could do it the other way around and say that cross-origin iframes by default disable vibration, but can then be explicitly re-enable the vibrator. We could implement a "allow by default but allow parent website to disable vibration" by extending the sandbox attribute. We could probably do audio tha</pre> Jonas Sicking 2012-05-03T11:05:38 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.mozilla.security