On 04/04/2016 22:28, Johann v. Preu?en wrote: > i am not certain i understand how it is google's fault that this > owenevans98|Dawn was able to slip into the listserv database. this is, > of course, assuming that this was not done via a simple sign-up. i > also do not understand how prohibiting a posting (content, infra) that > obfuscates a message within a host of symbols with a net zero percent > of prose and 100% anchor description is responding to some sort of a > "fad". this list is re problems and solutions that can only be > conveyed in prose ... no prose == no message. and permitting private > anchors is also a questionable security practice. it does not seem > unreasonable to require anchors to be to _recognized_ sandbox sites or > -- much better -- to an openssl-operated one. > No one (until about 2 hours ago) were discussing how the particular "From" address got past the "you must be subscribed to post" filter, maybe the spoofed From address happened to be a subscriber, maybe there is a bug in the list management software or configuration. There was discussion of which generic "hard-reject" filters should be applied and someone suggested prematurely applying a number of recently "trendy" such rules promoted by (ironically in this case) Google and others. I was the one who used the word "fad" to refer to such recently promoted "hard-reject" rules and pointed out that many smaller organizations will be unable to cause legitimate mail/postings to comply with such rules anytime soon, simply because it takes time to roll out new protocols to all the worlds legitimate e-mail sending servers. As for the suggestion to forbid links to servers other than OpenSSL.org servers, this will be fatally flawed as it will block discussions of such common OpenSSL related topics as: - URLs of published security research (such as the home pages of new vulnerability descriptions). - URLs of sites that publish OpenSSL related software, such as OpenSSH, stunnel, the Shining Light Windows binaries of OpenSSL etc. - URLs that are showing interoperability problems with OpenSSL. - URLs of independently published OpenSSL patches (that have not yet been accepted into the OpenSSL repositories). - URLs necessitated by the byzantine legal rules regarding which web servers are allowed to publish cryptographic software written by which people for use by which other people. These categories of non-openssl.org URLs occur frequently in legitimate posts to this list and cannot be replaced by some private openssl.org hosted equivalent of pastebin.com etc. > moreover, as i pointed out in a pm to Steve, this is a real security > issue for openssl's list in that such a breach (if it is one) opens > the names and email contact info of a broad range of > security-responsible people that will invariably include some in the > upper regions of the perm chain. these people are the very people that > are targeted by malicious attempts (and some startling successes) to > breach much more than an organization's email system. You are now going way outside anything discussed previously, please enlighten the list as to what you are possibly talking about here. So far the only known breach is an apparent breach of *Google owned* e-mail servers, allowing perfect spoofing of gmail.com addresses by causing the fake mail to be sent by *exactly* the same servers with *exactly* the same headers as legitimate mails by the legitimate user of the spoofed e-mail address. This does not expose any of the names of any e-mail addresses stored by the OpenSSL organization, unless that data can be extracted by e-mailing a command to listserv from a spoofed administrator e-mail address and any of those administrator e-mail addresses are actually hosted by Google. > > yes, this person has seemingly stopped with postings, but i am hearing > no assurance that they have even been eliminated from the subscription > database. just being able to listen will garner a wealth of sensitive > info obtainable re a most desirable crowd of people/victims. > Posts by others indicate that the *spoofing* activity seemed to have stopped for multiple gmail addresses, including the e-mail address of one person posting such an observation, indicating a likelihood that Google fixed the underlying security issue. > even the most simplistic listserv app has the ability to withhold > subscriber email addr's and still provide a secure pm capability. now > that it is apparent|perceived that the list is vulnerable, i believe > the prudent route to go is to keep those addr's and subscriber > real-world names out of the "limelight". i see no reason why a > sanitized subscriber profile available from a link within the person's > public handle would not be adequate for identification purposes and > would actually become an enhancement to the listserv app's usefulness > to subscribers. this would certainly shield the subscriber in a > reliably meaningful way, serve to protect a subscriber's own email > system, and enhance the security of openssl's own listserv ops. The issue that the FROM addresses of OpenSSL e-mail list posters (not other subscribers) can be seen by anyone receiving or otherwise finding their postings is age-old and completely unrelated to any issue related to this discussion (the spammer in this case obviously did not know that this was a mailing list, given the incorrect textual name used with the list SMTP address). Even if OpenSSL were to switch to a surveillance vulnerable design where PMs between users would have to go through the OpenSSL servers, the list administrators will probably remain reachable using well known mandatory e-mail addresses such as "Postmaster". A similar issue would apply to most of the other high value subscribers. Any such people would already be required (in order to perform their function safely at all) to employ security measures to isolate their publicly known e-mail addresses from any e-mail addresses that are not intended to be publicly known. As an example, all my (non-blocked) postings on this list use a dedicated mail address and mail box which allows me to dismiss e-mails on other subjects to this address as Spam while not exposing other e-mail addresses used for more trusted uses, and I obviously employ similar measures for any well known role accounts I handle myself. > *original anchor description (100% of the message content):* > Attn:__here__is__your___$l?? ?? ?? __Faceb????k__giftcard. > > __W??__N????d__Y????r__Shi??me??t__Inf??rmati????s__ > > Click_Here > > On 2016.Apr.04 09:08, Jeffrey Walton wrote: >>> And anyway, this seems to be a case where the genuine >>> operator of an e-mail domain is failing to correctly >>> authenticate submissions by their own users, which no >>> amount of 3rd party automation (other than blacklisting >>> the failing provider, in this case gmail) could stop. >> Yeah, I'm guessing there was a vulnerability in one of the other >> Google services, and that Google service was allowed to make web-based >> email submissions on behalf of the user. Classic injection and failure >> to validate sessions or parameters... >> >> I'm also guessing Google fixed it because it has stopped. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160405/3f758939/attachment.html>
