On 05/04/2016 01:47, Johann v. Preußen wrote:
'/No one (until about 2 hours ago) were discussing how the //
//particular "From" address got past the "you must be //
//subscribed to post" filter/'
actually, i first posted on this issue c. 76 hours ago.
Not in this thread on openssl-users as far as I can tell.
'/maybe the spoofed From address happened to be a subscriber/'
is it possible that openssl still does not know if the email addr is a
real subscriber?
I have no way of knowing since I am not one of the list admins.
'/maybe there is a bug in the list management software or configuration/'
yes, i surely hope someone is looking into this possibility.
further, not only was owenevans98 able to post an original message (the
subject of this thread), but there was a subsequent posting in reply to
another thread. thus, the conclusion that owenevans98 was not only able
to post but was|is receiving the listserv mailings is self-evident. the
fact that this two-way comm path came into existence means that the
listserv database was corrupted and that the original posting was not
some slip-up in permitting an un-authorized one-time posting.
Which other thread was that?
jakob, i appreciate your taking of the time to detail some of openssl's
listserv practices and view-points. perhaps it is best to set forth the
synopses of my views:
I am not a list admin or other official team member, I am just an
active list member who wants to avoid the list admins following bad
advice from people like you and Ben Humpert.
1. make certain ' owenevans98' and any other illegitimate posters are
not receiving listserv mailings;
Question is if owenevans97 is an illegitimate poster or a legitimate
poster whose e-mail address was spoofed.
Anyway, the OpenSSL mailings are all being indexed on the world wide
web by multiple organizations, where anyone can read them.
2. stop publishing the subscriber's protected PII in the clear; and
Again, I see no sign this is happening other than the age-old inclusion
of original from and reply addresses in postings (which is limited to
those who post, and doesn't affect those who only subscribe).
3. control postings of anchors.
I disagree. A number of e-mail clients (MUAs) automatically turn
textual URLs into anchors and make it very difficult (if not
impossible) for the posting user to avoid this. And people
professional enough to understand most of the stuff on OpenSSL mailing
list also know not to click on links in strange e-mails and forum posts.
according to your comment quoted, supra, it seems that the step
indicated in Item 1 has yet to be taken.
I wouldn't know.
Item 2 can be implemented by inaugurating a subscriber-managed profile
and merely publishing a user handle linked thereto. thus, you can shift
the onus to the subscriber to reveal whatever info they wish rather than
arbitrarily exposing to the world a subscriber's personal name, email
addr, and work-force association.
Did you read and understand any of that which I wrote, or
are you just trolling?
in the case of Item 3, i understand all of the reasons for having links
(not html anchors) in postings. it is a very minor inconvenience for
someone who has a burning interest in viewing a link to copy the
clear-text link into a browser versus clicking on an anchor description
which could lead the subscriber far astray from what the description
says. it also enhances the subscriber experience to visually see where
the link is going instead of having the actual target obscured by a
description that may be deceptive, merely misleading, or non-apparent
(i.e., 'click here').
jakob, you also mention concern re MTA operators having some issues with
changes you may make to the listserv ops. please note: none of the three
(3) items, supra, i have suggested have any impact on other MTA
operators as they are totally internal-control enhancement proc's.
I am an MTA operator, I am not a listserv op. I was posting concerns I
have as an MTA operator and list member with stupid changes suggested
by you and Ben Humpert.
i cannot understand why openssl's filtering missed the fact that the
posting that is subject of this thread predominated in symbols and
control characters, contained no actual message text, and still went
through. hopefully, someone is also looking into why this happened.
Did you read the brief but very clear message posted on 2016-04-02
15:24 UTC by Rich Salz (who is an OpenSSL team member and may have
access to the listserv configuration details not published to avoid
helping spammers)?
P.S.
Please don't CC list members on replies to the list, it causes
duplicate copies to reach them (since list membership is required to
post to the list anyway).
On 2016.Apr.04 15:36, Jakob Bohm wrote:
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
