Slashdot Mirror


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.

2 of 109 comments (clear)

  1. Similar experience by Ecuador · · Score: 4, Informative

    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.

    --
    Violence is the last refuge of the incompetent. Polar Scope Align for iOS
    1. Re:Similar experience by TheRaven64 · · Score: 4, Informative
      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.

      --
      I am TheRaven on Soylent News