iCloud Allegedly Locked Out User Whose Last Name is a Boolean Value (engadget.com) 208
"iCloud has had the occasional service issue, but its latest problem appears to be highly... specific," writes Engadget:
Actor and author Rachel True claims iCloud has effectively locked her out of her account due to the way her last name was written. Reportedly, her Mac thought lower-case "true" was a Boolean (true or false) flag, leading the iCloud software on the computer to seize up. The problem has persisted for over six months, she said.
True said she'd spent hours talking to customer service, and that Apple hadn't stopped charging her for service. She could switch to the free tier, although she'd also lose most of her online storage if she did.
True has apparently resorted to imploring desperately in tweets to both @Apple and @AppleSupport. "Now that I a layman have explained problem to you a giant computer company, could u fix...?"
"A thing I've learned about life so far is I hate being the test case."
"When I get a dog I'm naming it Boolean Bobby Drop Tables True"
True said she'd spent hours talking to customer service, and that Apple hadn't stopped charging her for service. She could switch to the free tier, although she'd also lose most of her online storage if she did.
True has apparently resorted to imploring desperately in tweets to both @Apple and @AppleSupport. "Now that I a layman have explained problem to you a giant computer company, could u fix...?"
"A thing I've learned about life so far is I hate being the test case."
"When I get a dog I'm naming it Boolean Bobby Drop Tables True"
xkcd (Score:5, Insightful)
Re: (Score:2)
And parent should be modded funnier than insightful...
Re:xkcd (Score:4, Insightful)
One could suggest that ingesting to suitable variable for preprocessing and validation is "sanitizing"
Re: (Score:2)
Re: (Score:2)
The simplest way is to use sql query parameterization [w3schools.com]. Look at the "// prepare and bind" section for details.
Re: xkcd (Score:2)
She needs to change her name to false I believe, or even better null
Re: (Score:2)
Re: xkcd (Score:5, Insightful)
No. Bad boy.
There are hard rules of syntax that, when applied by a programmer with half a brain, guarantee that code and data cannot be used interchangeably.
There are no values that a surname or name can be that should at all cause any issue to a half decent programmer. Doesn't matter if the guys name is "Null", "True", or "0x57489".
Re:xkcd (Score:5, Informative)
What do you mean? Mr. Null's last name does not need to be sanitized. It just needs to be preserved as text, rather than mistaken for a reserved word or other special value. That's the same lesson that little Bobby Tables teaches.
Re: (Score:3)
I agree with you, but given some of the bizarre convoluted input handling code I have seen - much of which would reject last names of True and Null at an early stage - there are a lot of coders out there who don't understand what you are saying.
Re: (Score:3)
That's because they don't understand the problem or what they are doing. There is very little good reason for "input handling" code beyond bounding lengths. There is ample reason for being safe about types and especially about string interpolation and concatenation.
Re: (Score:3)
I agree with you, but given some of the bizarre convoluted input handling code I have seen - much of which would reject last names of True and Null at an early stage - there are a lot of coders out there who don't understand what you are saying.
No argument about that. We have far too many coders on this planet and most of them barely know what they are doing.
Re: (Score:3)
Re:xkcd (Score:4, Informative)
And yeah, their use of 'hacker' in the title is
Re: (Score:3)
Re: (Score:2)
Mostly, I use prepared statements. The variables in the SQL statement are marked by question marks, and they get populated with text strings by reference. I don't worry about escape sequences, unless for some reason I want to handle NUL bytes, because I work in C++ and a lot of functions think NUL terminates a string.
Your comment is not really about sanitization, it's about proper quoting -- and that is only needed when you want to treat external (suspect) data as trusted. Keep your string data as string
Re: (Score:2)
store every! user input/variable with the letters zf appended as a prefix;
on every display use of it trim the zf
does that work?
Re: (Score:2)
Re: (Score:2)
really... concatenation of garbage that can be stripped to ensure it never matches a valid label that will evaluate
because it is lame? or because it won't work? you could substitute for any command elements like operands...
it can be done.... it's just lame.
Re: (Score:3)
Let's try your proposal with little Bobby:
Robert'); DROP TABLE students;--
becomes:
zfRobert'); DROP TABLE students;--
See? The parents will still get that call.
Re: (Score:3)
Re: (Score:2)
When you put it that way, it's even harder to understand. Is it possible that it's a deliberately forbidden name? Maybe there was some ingenious troll who used the name "True" in such an annoying way that Apple has now decreed "True names must not be allowed"?
In other words, maybe it's a feature, not a bug?
(But in that case, Apple would have to filter names for words corresponding to "true" in every language?)
You mean like this? (Score:2)
Re: (Score:2)
Of course True names are not allowed - giving your true name to someone else gives them ultimate power over you.
Re: (Score:2)
Perhaps we should really see this as a language problem. The language should always assume that "null" is a string and provide a function to test the value:
Instead of:
<string variable> == null;
use:
isNull(<string variable>);
The former should simply be a syntax error, since, in this scenario, 'null' should be quoted:
<string variable> == "null";
Re: (Score:2)
Adding to this, "isNull()" should only accept a variable name, not a literal string.
Re:xkcd [is not False] (Score:3)
Or at least the joke isn't falsifiable, but I wanted to ask (or joke) about someone with the name "False".
However, I think this is a problem in the other direction. The user's name is a string that should not be "sanitized" in the way that Apple has decreed. Code is law, but this is a case of a stupid law.
TANSTA-BSD is especially applicable in this case, since that's where Apple's OS came from. However, in this case the BSD should stand for Benevolent Stable Dictatorship. A BSD always goes pear-shaped, soon
Re: (Score:3)
The correct answer should be "No".
Re: (Score:3)
I'm a reformed wife beater, you insensitive clod!
Re: (Score:2)
reformed wife beater
You mean an ironed one?
Re: (Score:2)
Wouldn't that be a reforged wife beater?
Re: (Score:2)
Are you joking? If so, I don't get it. Or perhaps English isn't your first language? Or you don't understand that your "No" answer is a confession to beating your wife? I suppose it's also possible that you believe every wife deserves to get beaten, so maybe you file wife-beating under "No harm, no foul"?
(I do get JonnyCalcutta's joke. In that case, "No" is appropriate.)
Re: (Score:3, Insightful)
English is my first language. I think you need to go back and study logic again.
If I have never beaten my wife, then, I have not stopped beating my wife. "No" is not a confession to beating.
Re: (Score:2)
https://www.google.com/search?... [google.com]
Re: (Score:3)
"Yet" doesn't change anything.
You fail at logic.
Re: (Score:2)
True enough, but we all know that the implications of that "No" will not be correctly understood by most people.
Prepared statements, data as data - not code (Score:5, Informative)
You're quite right that "sanitize inputs" is poorly phrased. Some checking to make sure that inputs are sane is wise, but that doesn't ensure safety, not at all.
Safety comes from thinking about where the data is GOING and handling the output in such as way that the next system knows that the data is data, not code.
For a SQL database, what makes it safe is to use what are called "prepared statements". That ensures that data, such as a text string, is treated as data, not as SQL code to be executed. Similarly, when you're writing to XML, cdata tags mark a section as data, not XML code. That needs to be combined with entity encoding. Similarly again for HTML output.
The same data may be inserted into a SQL database, then displayed in a web page, which also have a button to download as PDF or as a spreadsheet. Safety has to be done bases on where the data is GOING, not at input time. You aren't going to check all of your web inputs to ensure they don't include Excel functions such as max(). The time to handle that is when you produce an Excel spreadsheet from the data.
That said, again sure it makes makes sense to check that a price (a decimal number input) contains only numbers and a decimal point - not linefeeds and 0x0, the null character. That's just not where the primary safety comes from.
Re: (Score:2)
It's an interesting concept as standardized way of expressing parameterized queries in textual format.
Unfortunately, the person making the proposal emphasized early in the thread that "end data block" is undefined - the data block can never be ended. The proposer pointed out that's important. The proposal doesn't work without that.
Later in the thread the person answered another objection, the fact that one could only ever run only one query, by saying the next query starts after "end data block". At that
Re: (Score:3)
It is actually quite possible to sanitize input. It is just hard to do and error-prone because you have to understand what you are doing to do it correctly. Few "coders" these days fulfill that requirement. Hence usually you go for different approaches like prepared statements that do the sanitization for you.
Here's why it's impossibe (Score:2)
Here's why it's impossibe to "sanitize input", where "sanitize" means "make safe", as opposed to "ensure it is sane".
Is this input safe?:
Ray&Gweihir
Or:
Johnson&Johnson
If it's not safe, how would you make it safe?
Hint: it's one of the OWASP Top 10.
I'll let you think about that for a second, then check out my follow-up post.
Re: (Score:2)
Before talking about the value Johnson &Johnson, how about "max(", is max( safe? How about ABC, Inc?
Suppose you're making a some vaccine data processing application that outputs CSV. Johnson & Johnson value is safe, at the time you write the input code.
Later, perhaps you make the same data available via a web API of some kind, which sends data as XML of some sort. The value is no longer safe. Now it's potentially an XXE attack.
Put it in a web page? Different characters and strings become an issu
Re: (Score:3)
Because NULL and "NULL" are not the same thing.
The problem with Apple is that they're transmuting a string back to a literal, which is also potentially a security exploit depending on how/where it is used.
Re:xkcd (Score:5, Informative)
Consider former St. Louis Rams quarterback Keith Null - how does Mr. Randall propose to "sanitize" his last name?
This article from the BBC [bbc.com] from 5 years ago talks about this very subject. In fact, the person in question is Jennifer Null who was warned in advance the problems she might face when changing her name after getting married.
Apparently in five years all those vaunted programmers we keep hearing about with their six figure salaries can't figure this out. Makes one wonder if they're worth their pay.
Re: xkcd (Score:2)
Re: (Score:2)
It is not the programmers that have the problem. It is the minimum wage coders.
There's always an excuse, isn't there?
Re: (Score:2)
Don't use string concatenation for SQL queries is part of what is meant by "sanitize your database inputs"
Re:xkcd (Score:5, Interesting)
a cult45 neighbor is occasionally visited by an all-black dodge charger wagon festooned with antennae & sporting the license plate "NO TAG"
Unfortunately, that might not work the way he intended: https://www.slashgear.com/vani... [slashgear.com]
Really excellent test case (Score:3)
How many among us can be 100% sure that if every string field we sent up to the server in either a form POST or GET parameters were set to the value "true", we'd not see the same issue...
The second link especially shows the truth of what is going on, with a "Type error: cannot set value 'true' to property 'lastName'"!!
So that seems like something great to try out in unit, or at least UAT testing...
This is really where the type-nonchalance of JSON comes to bite you on the ass as the entire chain from entry to extraction should be able to ensure type. Or maybe just anything that reads values from JSON and is expecting a string, should treat any numbers/bools found as strings even if the JSON parser didn't think of them that way. Or maybe some kind of schema overlay where you could tell a parse explicitly what you expected type-wise out of dictionary keys and then it would always do that conversion.
Re: (Score:2)
Yes, something is rotten here with user input handling.
Re: Really excellent test case (Score:5, Insightful)
This has nothing to do with JSON. JSON makes a very clear distinction between boolean true and the string "true".
This is gross incompetence on Apple's part. It really makes you wonder what kind of security holes they've got unpatched due to accepting user input without validation.
Re: (Score:2)
This has nothing to do with JSON. JSON makes a very clear distinction between boolean true and the string "true".
Yep. The fun only starts to happen after you pass it through json_decode().
Re: (Score:2)
iCloud seems to have a history of poor security. All those hacked celebrity accounts were due to not limiting password attempts.
It has everything to do with JSON (Score:2)
Uh, no. It would be like finding that Google or Amazon is hosting a service for someone maliciously collecting user information.
Technically that is not correct, because true and true enclosed by quotes, are both strings that a JSON parser has to interpret in different ways... all of JSON is a string that you are parsing, so "value" : true and value : "true" will both parse just fine, even though one results in a type you do not want...
I have personally seen servers suddenly forget to quote some strings tha
Re: (Score:2)
How many among us can be 100% sure that if every string field we sent up to the server in either a form POST or GET parameters were set to the value "true", we'd not see the same issue...
The majority of servers are running a language designed by clowns, that's true, but they usually have operators like '===' and '!==' for comparing strings without converting things like "true" into a double precision 1.0 for the comparison.
Re: (Score:2)
Re: (Score:3)
No, it absolutely has to do with computer languages. Specifically, it's the difference between weakly and strongly typed languages.
I would bet that, at some point, most issues that someone has with a name like "Null" or "False" means that there was a bug in some JavaScript code somewhere (oops, not enough equal signs), because it's all too easy to accidentally convert strings to Booleans or numbers or nulls. This an inherent flaw of the language (in the form of a convenient feature), in the same way that
Re:Really excellent test case (Score:5, Insightful)
That doesn't sound like JSON, that sounds like a poorly written HTTP form parser. JSON makes a clear distinction between booleans (true, false) and strings of those booleans ("true", "false").
HTTP form parameters are just strings, which means that they have no inherent type, which means that trying to be "too clever" with parsing them can lead to things like seeing lastName=True and deciding that True means boolean. (A similar thing happens with numbers: does foo=0 mean the number 0 or does it mean the string "0"? If all you have is the HTTP parameters, who knows?)
The HTTP form parser should just parse to string key and string value pairs (well, string array values - keys can and will appear multiple times and you need to be prepared to handle this) and then offer convenience methods to convert to proper types when the type is known. Trying to pre-convert types leads to this bug.
Re: (Score:2)
Re: (Score:3)
How many among us can be 100% sure that if every string field we sent up to the server in either a form POST or GET parameters were set to the value "true", we'd not see the same issue...
I can. Why? Because I use prepared statements for all database interactions. Anyone using inline SQL even one time needs to be pulled from their job immediately and retrained. Anyone using it twice needs to be reprimanded. Anyone using it three times needs to be demoted (and perhaps put on unpaid leave). Anyone using it four times needs to be fired.
This has been a solved problem for decades, and any project subject to SQL injection just demonstrates gross incompetence.
Re: (Score:2)
Bring iCloud down (Score:2)
With a carefully worded name.
Then you'll get attention.
You think that's bad? (Score:5, Funny)
My last name is /0
Re: (Score:2)
That's fine, but probably lucky that it's not \0. (or is that what you meant? Or is there a language I'm not familiar with that treats forward slashes as an escape sequence?)
Re: (Score:2)
It has been a billion years since I worked with any IBM JCL but IIRC a forward slash was a control signal in that bizarre language.
Re: (Score:3)
No. // was the introducer for a JCL control card/statement. /* signalled end-of-stream. /0 was nothing at all (that is, was either part of a stream or, if a statement was expected then it was an error).
Re: (Score:2)
Nope, was just thinking "divide by zero". But if you start analyzing it, it doesn't work.
Maybe I could have done something with a ternary operator...
Re: (Score:2)
I have a normal last name, but my iTunes account was deleted right after I uploaded my Spandau Ballet tracks.
Re: (Score:2)
Bind variables (Score:5, Informative)
There are also a number of people in the US named Null, as in former St. Louis Rams quarterback Keith Null. One should never be creating code that directly compares information received from an external source to a string - the external information should always be ingested into a variable of suitable type and then preprocessed before comparison to another variable.
Re: (Score:2)
Indeed. This is the very embodiment of what makes injection-attacks possible.
Of course, the injection attack refuses to die, so the utterly incompetent coders stay active and "contribute" in a lot of places.
And I thought I had problems ... (Score:2)
And I thought I had problems ... I have it easy!
Sincerely,
Bobby print_r($output,true); die();
This doesn't pass my sniff test.... (Score:2)
Sorry, but "racheltrue@icloud.com" has no delimiters that might mess with a concatenated query, and definitely would not affect properly sanitized, delimited, quoted string parameters for a SQL query.
I would have to see the code to understand how this could mess up validation for her login. Using an IndexOf or Contains for "true" makes no sense, in any context, either. I can't fathom even a bad coding scenario where that might happen.
On the other hand, if it had to be coded in one of Apple's non-industry st
Re: (Score:2)
Sorry, but "racheltrue@icloud.com" has no delimiters that might mess with a concatenated query, and definitely would not affect properly sanitized, delimited, quoted string parameters for a SQL query.
I would have to see the code to understand how this could mess up validation for her login. Using an IndexOf or Contains for "true" makes no sense, in any context, either. I can't fathom even a bad coding scenario where that might happen.
On the other hand, if it had to be coded in one of Apple's non-industry standard language de jours, I suppose there could be some room for massive fail.
Bets on whether there's still WebObjects code in there somewhere?
Re: (Score:2)
Well, looking at the error now, I guess it was specifically an issue with her last name, and probably something generically taking the serialized data and changing "True" to true without consideration for the data type.
Ugh. ...and yes, for the record, I absolutely hate fad languages and this ADD approach to computer science. There is something to be said for sticking with time-tested languages and tools, with mature, robust libraries, rather than turning to the next "shiny thing" either to be cool and hip,
Re: (Score:3)
Ugh. ...and yes, for the record, I absolutely hate fad languages and this ADD approach to computer science. There is something to be said for sticking with time-tested languages and tools, with mature, robust libraries, rather than turning to the next "shiny thing" either to be cool and hip, or simply to be proprietary (as usually the case with Apple) for the sake of "think different" or maybe more correctly "lock out other platforms".
Apple used straight C as its primary language for many years, until adopting Objective C (a strict superset of C) as its system language for OSX and later iOS. Objective C was created in 1984 and was Apple's most-used language until around 2018--does that count as time tested? gcc has supported Objective C for almost that entire period.
Here are some popular languages that did not exist in 1984. Python, Perl, Java, and ... C++.
Apple released Swift, an open source language, under the Apache license, ~6 years
And you would be wrong. (Score:3)
Sorry, but "racheltrue@icloud.com" has no delimiters that might mess with a concatenated query, and definitely would not affect properly sanitized, delimited, quoted string parameters for a SQL query.
It's not an SQL issue. just look at the error: https://twitter.com/RachelTrue... [twitter.com]
Re: (Score:3)
The variable got automatically typed to a boolean.
Python doesn't do that.
However, inexperienced Python programmers think "Instead of specifically converting certain values in this dict, I'll just do one convenient for loop over all the values!"
Bullshit article (Score:2)
The fact is, if her name was "true" then everything would work.
Every good developer knows that with speculative execution positive test branches are faster, so developers are testing for true, not false.
And anyway, nobody actually looks at the name; they're looking at the GUID that represents the name.
Maybe she forgot to send in her trade-in, like the last guy in the other the bullshit Apple article.
Crapcode (Score:2)
Nobody halfway competent would write software with this issue. Looks like they are now having fully incompetent "software developers" wrote important stuff.
Re: (Score:2)
Possibly. But that still means you have some incompetent coders in there, because something like this is a clear "must not happen" to anybody competent. Type checks or type enforcement in Python only takes minimal extra effort, and this is a place where it must be done.
Also note that "experienced" does in no way imply "competent".
experience vs competence (Score:2)
>
Also note that "experienced" does in no way imply "competent".
It used to. In the early 1970s, if you had 10 years of computer experience you were assumed to be competent.
I learned this while taking my draft examination. I happened to mention that I had 10 years of computer experience while talking to an Army recruiter. The Army Intelligence guy at the back of the office looked up when I said that, and asked the recruiter to send me to him when I was finished. We had a nice chat, and he contacted me later when my intelligence tests came in. Had I been willing to c
Re: (Score:2)
>
Also note that "experienced" does in no way imply "competent".
It used to. In the early 1970s, if you had 10 years of computer experience you were assumed to be competent.
I agree to that. This probably stayed mostly true until Java came along and more and more people mistook some Microsoft "OS" as suitable to run servers on. But that was before programmers got coddled and infantilized with IDEs that complete code and libraries for everything. Back then you only managed to get things to work if you did know what you were doing. Not so anymore. As a consequence, many bad coders get things to sort-of work, but have horrible surprises (both with regards to security and to corre
Information: the actual problem. (Score:5, Informative)
If you look at the image of the actual error [twitter.com] you will realize this is a client problem. What has happened is that when the program read the iCloud information it is reading variable values from a text source (e.g. config file) and it's then assigning the values to variables. When it parses the text "True" it converts it into a boolean value. However, the destination variable is a string. The result is the program throws an error saying there is a type mismatch.
This is a client-side bug in the software, likely a config file parsing library. The program initially accepted the value from text entry and stored it in some config file. When the config file is read back then it erroneously interprets the value as being boolean.
Re: (Score:2)
The program is trusting user-controlled input without adequate sanitisation.
This is a trivial class of problem that SHOULD NOT HAPPEN, but in this instance it's the most minor of knock-on effects, locking a user out of their account.
That this entire class of problem exists is far more serious, because what else is that program interpreting literally rather than sanitising first from that configuration file, what permissions does it run with, and what could you make it evaluate other than just True?
Simply sh
Wrong. (Score:3)
The program is trusting user-controlled input without adequate sanitisation.
There is nothing wrong with the value "True" which is why it accepted it. The problem is with how the value is interpreted after it is was read from a stored copy.
This is a trivial class of problem that SHOULD NOT HAPPEN
This much is true. It's just a guess but it seems like it's reading in a quoted value, stripping the quotes, and then deciding the type of value it should be. Then again, if it wasn't a quoted value to start with then that is a serious flaw.
Re: (Score:2)
Re: (Score:2)
The library parsing the config file has no idea what the values are supposed to be, so it detects the type of values. In this case it does so incorrectly because it thinks "True" is a boolean value. When the program tries to assign this value to the variable, it throws an unhandled exception because it was expecting a string.
"Allegedly" (Score:5, Insightful)
So when it's an apple bug, it's "allegedly"?
Re: (Score:2)
It never changes. (Score:2)
True story, bro (Score:2)
I swear.
Dog names ... (Score:2)
When I get a dog I'm naming it Boolean Bobby Drop Tables True
Follow Steve Wright's lead [dogquotations.com] and name it "Stay":
I bought a dog the other day. I named him Stay. It's fun to call him. "Come here, Stay! Come here, Stay!" He went insane. Now he just ignores me and keeps typing. He's an East German Shepherd.
Then take it for a walk -- one:
I took my dog for a walk, all the way from New York to Florida. I said to him "There, now you're done."
Bullshit (Score:2)
Re: (Score:2)
JavaScript is (dynamically typed languages are evil :P)
She should stop being such a drama queen (Score:2)
people with names like root, admin, sys, super, (Score:2)
people with names like root, admin, sys, superuser, administrator, etc?
people with names the same as the vendor?
May blocked on cloud systems.
Re: (Score:2)
This story sounds plausible when you consider what company we're talking about. Remember that iCloud was renamed from MobileMe because the previous version was such a reliability disaster that they were embarrassed about it. And before that, MobileMe was renamed from .Mac for the same reason. And before that, they renamed .Mac from iTools for the same reason (and/or to charge money for it; hard to say; maybe both).
Apple builds decent operating systems and usually decent apps, but their server infrastruct
Re:False, more likely. (Score:4, Informative)
This bug is so unbelievable I cannot even conceive of an algorithm that makes it possible. I need more evidence for its existence.
You've obviously never compared two values using '==' in PHP, a mystical land where "true"==true, where true==1, but 1!="true"
http://phpsadness.com/sad/52 [phpsadness.com]
Re: (Score:3, Insightful)
Whining doesn't change that.
Re: (Score:2)
And how is that endemic to just python? A lot of languages would let you convert types. Even languages that have more strict typing rules often let you coerce type.
No matter how good a language is, someone will find a way to use it badly. All the standards in the world can't prevent that (nor should they; there's no excuse for incompetent programming).