“Please do not make it public” (Tencent’s Sogou Input Method)
citizenlab.ca
citizenlab.ca
> Vulnerability disclosed to IMETS@tencent.com.
> Vulnerability disclosed again via Tencent Security Response Centre (TSRC) web portal.
> Tencent: “Thank you for your interest in Tencent security. There is no low or low security risk for this issue. We look forward to your next more exciting report.”
> Tencent: “Sorry, my previous reply was wrong, we are dealing with this vulnerability, please do not make it public, thank you very much for your report.”
> Tencent’s initial rejection of our disclosure and subsequent about-face served as inspiration for the title of this report.
It's a direct quote from a Tencent reply.
The title induces readers into thinking that they said this in some other context. Example 1: They aren't working toward fixing it, don't release this, lets just keep it hush hush. This isn't what happened. Example 2: They did fix it, but they didn't want the researcher to publish details of the problem after they fixed it. This also isn't what happened.
Assuming I understand the context correctly; its absolutely an inflammatory title that has no place in security disclosure articles like this.
If they were English speakers they would've written something along the lines of "We thank you that you respected the vulnerability disclosure policy and notified us. We expect you'll continue respecting the policy and not publish this vulnerability before we resolve the issue and after a period of time where the updated software has been uploaded."
Chinese culture had a very strong "save face" mentality, especially big companies that have much government involvement. So they aren't going to admit fault or indicate that they have to do something.
The correct response to tencent's initial response, was to say that you are looking for status update and will disclose vulnerability by X time. Please let us know when the issue has been fixed.
Ok, so they didn't make it public and the development team fixed the bugs.
Maybe I am missing some new trend where the headline in these disclosures _has_ to come from the communication with the company. Kind of like vulnerabilities need custom websites with logos and cool made up names?
> Even with the reported vulnerabilities now resolved, the Sogou app relies on transmitting typed content to Sogou’s servers as part of its ordinary functionality.
Well besides the email firewall mess back and forth, shouldn't that have been the main headline: "Everything you're typing on your keyboard is being sent to China"?
I’m very interested in better understanding this. Why do they elect to do this? Is this just developer hubris, as found everywhere? Does this relate to government regulation or control, whether above or under the table?
Understanding how to use eg. OpenSSL APIs correctly to ensure that a connection is secure, the certificates are valid, etc. is not trivial. The APIs are poorly documented, hard to use, and many examples you can find are outdated (some OpenSSL APIs return different numbers on success/failure depending on version).
The platform native libraries are not much better. For example, the SecTrust APIs on macOS / iOS are also poorly documented, hard to use, and have bugs (eg. some time ago they suddenly started to reject valid certificates from Google cloud for some reason).
Also, your code is always a ticking time bomb, because TLS algorithms are deprecated, certificates expire, etc. So you are always at the risk of your client code to stop working at some point.
So in my opinion, there are often good reasons not to use TLS. But if you make a mistake, everyone will say "You should have used TLS". I wonder what people say when they find a bug despite you using standard crypto?
Not using TLS doesn't automatically mean you need to "roll your own crypto". They could have used a well documentend library such as Google Tink[1] instead of doing their own crypto.
> Also, your code is always a ticking time bomb, because TLS algorithms are deprecated, certificates expire, etc. So you are always at the risk of your client code to stop working at some point.
Certificate expiration should be handled as part of the configuration management lifecycle. Same goes for TLS algos. If you are hardcoding either of these, you are definitely doing something wrong.
For OpenSSL, app developers don't need it. There is OS builtin libraries to do http requests (which is what was done here).
As for certificates, there is plenty of solutions allowing for auto-renewal. It's very easy to set up using automation.
If all you want to do is fetch an URL from a public HTTPS server, then I agree.
If you want to do anything even slightly more complex (eg. pin a specific cert, or use TLS with a protocol other than HTTPS) then the built in APIs are almost as bad as OpenSSL (at least on macOS/iOS, I don't know other platforms).
> As for certificates, there is plenty of solutions allowing for auto-renewal.
It's not a problem on the server side. It's a problem on the client side when the root certs expire. It puts an expiration date on your software.
I would understand (not approve of it, but merely understand) completely ignoring security/authentication - that would obviously be easier and avoid having to answer hard questions and make hard decisions.
But here it seems like they've put even more effort actually designing some custom encryption scheme based on (wrongly-applied) cryptographic primitives complete with custom request encapsulation format, etc. This is more work than just swapping your TCP channel with a TLS one and reasonably trivial auxiliary code to load/renew certificates. In this case since they're running it over HTTP it's even easier to just put a reverse-proxy in front that will add HTTPS on top.
They could be rightly suspicious of a western TLS implementation but discovered the pitfall of writing their own. Could have also been intentional.
They could have deployed TLS with some cipher of Chinese origin, not like Chinese companies haven't done this before [0]
So the NSA would purposefully embed an exploitable bug in a cipher they themselves use?
> … it would be about compromising security on the software level rather than the encryption level
Those are two very different things. A cipher could very well be exploitable. What you are talking about is the implementation.
In other words, a vulnerable cipher would be exploitable regardless of the implementation.
It is not the case, though. They tried to deploy their own protocol on top of a well known cipher.
It's always a mistake, though. This is something I had to cover with younger devs quite a bit back when I worked for a company that made heavy use of cryptography.
It seems like this could be in part mitigated by making sure their server is not an oracle (though obviously fixing the primitives is also important, but older/non-updatable clients could exist).
I would guess the traffic all over TLS on iOS due to "App Transport Security" requiring https by default - it's not a huge leap to turn it off, but it's controlled by the App's Info.plist so is trivially indexable. Also probably more work than just adding 's' to the protocol (at least from the PoV of the individual dev working on the code).
Windows OS pinyin->character input.... I don't know if I've ever seen someone use something other than Sogou lol, so honestly I can't say how good or bad windows native is at this now.
It's a hard problem, because of the 1:many fanout for any given pinyin input. "bao" can mean like 40 different things - bread thing, weak (?), hug, violence (?), treasured-one (think like "my precious", like a pet name for a baby?), etc etc. Sogou had a big leg up for a long time because it figured out the correct words from context much better than other alternatives, requiring fewer manual selections.
(semi-related note, google's voice->text still fails pretty hard for regional mandarin. For example it really doesn't like the hard Rs at the end of words in far northeastern mandarin. It can't seem to figure out that "baoERRRR" is actually just "bao". That problem doesn't exist for pinyin->characters though)
American companies man. They really don't care. So much stuff just breaks or does the bare minimum if you're using any kind of IME, or if you're not using UTF8, or even if you're not using ASCII. There seems to just be a general cultural incomprehension that there's any other way of writing on computers. (It's not even limited to companies - there's a whole bunch of Linux stuff with the same problem, e.g. Snap/FlatPak just break everything and don't care)
Anyone?
> While alphabetic keyboards typically provide autocomplete features for more expedient typing, predictive features in Chinese input methods are more crucial when using input methods such as pinyin where hundreds of characters might match an inputted pinyin syllable. For longer strings of syllables, an IME will commonly reach out over the network to a cloud-based service for suggestions if suitable suggestions are not available in the input method’s local database.
Not saying whether they should, but it's pretty easy to understand why they do it.
On the consumer privacy side, talking about consumer data safety from companies using it for commercial exploitation, that's where there is allowable space to be protective, and the laws reflect that in the PRC. If Tencent was found to be doing something that was seriously exploitative of user privacy in a way that made enough Chinese very angry, it would be almost certain that Tencent would be breaking some law to do so, and depending on the circumstances you could see anything from mandatory "make it right" directives from the government to the execution of Pony Ma as a result. PRC citizenry expect that if they are seriously harmed, en masse, by a company, the government will make it right.
This is a very different environment and culture from what we have in the West. In general, if I was the victim of significant harm (alongside many other people) by a large corporation, I would not expect justice. The CEO or those who made the decisions that harmed me wouldn't be executed, the company wouldn't be forced to push an update making my device safe to use again or pay a full refund to everyone, etc. As a result, if I care about this issue I'm not really thinking about the consequences for big companies of harming me, I'm just thinking about how to protect myself. What software can I individually use to protect my privacy, what companies should I individually avoid because I know I don't like what they're doing, etc. These are philosophically quite different approaches to privacy concerns - we have a lot more individual freedom in the West if we choose to use it, when it comes to individual net privacy, but the general attitude of PRC is that they don't have to worry about the privacy thing because the government will handle it one way or another.
Yes, in large part.
Also, implementing good cryptography requires specialist mathematical skills on par with dev skills. It's very easy to make a really trivial mistake such that it looks like the crypto is solid, when it's in fact very weak.
The ability to make a trivial mistake that's hard to spot, combined with the high stakes involved, makes cryptography something that's better left to the experts.
We used to call these things "keyloggers".