Security Researcher Says Samsung's Tizen OS Is The Worst Code He's Ever Seen (vice.com)

Samsung has been working on its Tizen operating system for several years now, implementing it into its various televisions and smartwatches. According to a report from Motherboard, the OS isn't receiving a lot of praise in the security department. Israeli researcher Amihai Neiderman has found 40 unknown zero-day vulnerabilities in Tizen, adding that it may be the worst code he's ever seen. From the report: "It may be the worst code I've ever seen," he told Motherboard in advance of a talk about his research that he is scheduled to deliver at Kaspersky Lab's Security Analyst Summit on the island of St. Maarten on Monday. "Everything you can do wrong there, they do it. You can see that nobody with any understanding of security looked at this code or wrote it. It's like taking an undergraduate and letting him program your software." All of the vulnerabilities would allow hackers to take control of a Samsung device from afar, in what's called remote-code execution. But one security hole Neiderman uncovered was particularly critical. It involves Samsung's TizenStore app -- Samsung's version of Google Play Store -- which delivers apps and software updates to Tizen devices. Neiderman says a flaw in its design allowed him to hijack the software to deliver malicious code to his Samsung TV. Because the TizenStore software operates with the highest privileges you can get on a device, it's the Holy Grail for a hacker who can abuse it. Although TizenStore does use authentication to make sure only authorized Samsung software gets installed on a device, Neiderman found a heap-overflow vulnerability that gave him control before that authentication function kicked in. Although researchers have uncovered problems with other Samsung devices in the past, Tizen has escaped extensive scrutiny from the security community, probably because it's not widely used on phones yet.

Comments

Re:Asian corporate culture...

[Zaelath]

It's an engineering problem.

Engineering proof of correctness: Does it work when I try to use it as designed?
Security proof of correctness: Does it fail open when I try to use it not as designed?

I've seen the same thing with firewalls; does it (the thing you're trying to access) work now? Ok the rules must be right then: "Allow any any" usually does it.

Not surprised

[gman003]

I was once asked by my boss to tinker with Tizen, see if it was usable, since a client was soliciting bids for an app they wanted to run on Samsung's smartwatch.

After a few day's experimentation, I reported that the Tizen SDK was basically unusable to write any app except the ones Samsung already wrote, and that the specific app the client was hoping for was literally impossible. The SDK itself was one of the worst programs I've used in many years - horrendously slow, crash-prone and cluttered in the way typical of early-00s Windows apps.

Needless to say, I am not surprised on multiple levels. First, that Tizen is insecure in addition to being slow and useless. Second, that nobody's taken a serious look at its security, since most people stop looking at it far before security starts to matter.

Embedded computing and security

[Opportunist]

Funny coincidence, I work in embedded in my spare time and am a security researcher by trade, so I think I can say with some confidence that they don't mix well. For many reasons.

First of all, there is no history of security in embedded. Because until very recently, there was absolutely no reason or need to even consider security an issue. You were dealing with closed, if not hermetically sealed systems. They could more often than not not even receive updates, let alone communicate with other embedded devices. Even "sophisticated" devices like TVs, not even talking about the "dumb" ones like washing machines or dishwashers. It's been only about a decade that TVs have a connection that's bidirectional. And "real" internet on TVs only arrived a generation of TVs ago.

And for all the other embedded gadgets, that whole "connectivity" thing is still very much bleeding edge.

And all that in devices for which until very recently, again, every byte mattered. Computer programmers are used to Mega- and Gigabytes of ram at their disposal, with embedded, you're in some areas still talking KB. Especially when it comes to low-cost devices where you can't just stuff in more ram and faster ICs because they'd simply cost too much. Yes, a part costing maybe a buck or two is "too expensive" here.

Put that together and add exactly ZERO experience with security among embedded developers (for all the reasons above) and you most likely understand why this is a HUGE problem that will bite us in the rear. Actually, it's already biting.

Similar experience

[Ecuador]

Similar experience, I thought maybe I'd look up at Tizen apps "for fun" and after about a day or so I was certain it was not going to be any sort of fun! Well, unless S&M is your thing... And here is an educational article about the EFL libraries you get to use when designing native Tizen apps.

Re:Similar experience

[TheRaven64]

Actually, the Daily WTF article is not particularly educational when it comes to EFL. It covers the obvious surface detail of what the developers do dangerously wrong. There are far worse things under the surface.

I had a chat to some of the Enlightenment devs at FOSDEM a few years ago. They were very proud of their new object system and IDL, which they thought would make it easy to bridge higher-level languages with their libraries. Unfortunately, their IDL exposed C types and nothing but C types as arguments. Their example had a char* parameter and a char* return. I asked them a few questions:

How do I know if it's and input or output (or both) parameter?

Is its length another argument (and, if so, in what units) or is it NULL-terminated?

Is there ownership transfer involved (i.e. is the caller still responsible for freeing the argument or does the callee take that responsibility? Is the caller responsible for freeing the return value and if so must they call free() or some other cleanup function)?

Is this an array of bytes or a string (i.e. should I map it to a string or data object in another language), if it's a string, what encoding does it expect and is that a global property or specified explicitly?

Apparently none of these questions had occurred to them and they didn't even understand why you'd want to know the answers to about half of them. The worst thing for me is that not only are these all important for bridging with higher-level languages, you need to know most of this information to be able to correctly use a C API, and they weren't putting it in the documentation and didn't even have consistent conventions (and therefore only need to document the exceptions). That was when I learned to avoid EFL like the plague. It may have improved since then, but I doubt it - good developers only reinvent the wheel after they've looked at existing ones and understood their flaws. The EFL developers are vaguely aware of square wheels and decided to try triangular ones as a replacement.

Tizen is summed up nicely by this TheDailyWTF post

[fistacorpse]

https://what.thedailywtf.com/t...