[Mailed and posted to list] On 2015-12-15, at 10:40 AM, Nils Dagsson Moskopp <n...@dieweltistgarnichtso.net> wrote: > > Jeffrey Goldberg <jeff...@goldmark.org> writes: > >> I work for a company that produces a consumer product for a number of >> different operating systems and environments as well as running a web >> service (written in Go). > > I sincerely doubt that security sells well in the consumer space. Think > about Windows, Android/Linux and the new internet of exploitable things.
We make 1Password, a password manager. So we are trying to sell security in the consumer space. >> Although I’ve been telling people to not use ad-hoc parsers and adding a >> new regex each time someone discovers a bug, it would be much much easier to >> persuade/force developers to do things right if I can actually offer them >> something concrete. > > I would appreciate if you would go into details about the product or > even show the code of a “typical” vulnerability that occured there. We produce a password manager, 1Password, that until recently was fully local. It does not talk to any service. There are cases where corrupt data can cause crashes, and presumably some injections of corrupt data could lead to local exploits. Our major data formats are publicly documented. E.g., https://support.1password.com/opvault-design/ But we have now launched a 1Password for Teams. This does involve a client/server protocol and it also during user registration handles user input. So we need to do a better job validating messages over the protocol and also validate user input. So far we haven’t hit an demonstrable vulnerability due to bad or inconsistant parsing. But we are running into problems simply because each platform is using its own ad-hoc parsing. For example, UUIDs are ASCII Hex representations of 16 byte random numbers. It turns out that not all of our platforms agree that both upper and lower case letters are acceptable. So some of what I am after isn’t so much about security (that will be a good side effect), but of being able to specify what is valid once and know that that is what will be recognized by each client. And because we’ve had some clients that accept some email addresses that others don’t handle, I thought it would be nice to be able to create a single grammar for email addresses that all clients could use. We have our fair share of bad and inconsistent parsing. And if we leave things as they are, someone will find some way to exploit it. We’ve been running a general semi-public bug bounty program, and while nothing catastrophic has been discovered, there is enough that suggests that we could benefit from more systematic data validation. > You should not validate inputs but outputs. Think about it: If you print > a string in an XML or HTML document, it needs to be escaped differently > than if you use it in an SQL statement or display it in a PDF document. Interesting point. Noted. > There exists an easy way to check if an email address is valid: Check if > it contains at least one @ sign, then verify if DNS gives you MX record. > I think it might be possible to ask the SMTP server if usernames exists. At this point we are not concerned whether an email address is deliverable, and I don’t really see why we should have to make name server resolver calls just to see if some data conforms to the format of an email address. Also you will not find many SMTP servers these days that enable VRFY. Also, I should point out that your scheme might consider foo@b...@gmail.com as a valid email address. It’s this sort of “at least one @ sign” that is the ad-hoc parsing that I’m trying to avoid. RFC2822 does give a grammar, and I would prefer to work from that. > Anything where you can have different types for textual content that is > of a different language (like HTML and plain text) might catch the most > obvious errors. See example from Chris Double with Rust phantom types: > <http://bluishcoder.co.nz/2013/08/15/phantom_types_in_rust.html> Thank you. I will take a look. Cheers, -j
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
