Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Operating Systems Privacy Security Software Hardware

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

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.
This discussion has been archived. No new comments can be posted.

Security Researcher Says Samsung's Tizen OS Is The Worst Code He's Ever Seen

Comments Filter:
  • by Anonymous Coward

    This just means Tizen is the appiest apperating app! Only LUDDITES would hate app-day apps!

    Apps!

  • by Type44Q ( 1233630 ) on Tuesday April 04, 2017 @06:46PM (#54174249)
    Asian corporate culture seems to get in the way of cranking-out good code; I wonder of that's because their management fails to realize that programming is as much an art as a science...
    • by Zaelath ( 2588189 ) on Tuesday April 04, 2017 @06:55PM (#54174313)

      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.

      • by gweihir ( 88907 )

        Actually, this is "bad engineering", because good engineering also looks at how it behaves under non-standard conditions and then you get security as a characteristic that can be tested and verified. I see the same thing when doing security evaluations and IT security engineering. People stop thinking when "it works" (not that many developers think a lot in the first place). A consequence is that you find, for example, all the "Web Application Worst Practices" in (custom) enterprise software. Add to that th

        • Yeah, I was a little unkind...

    • I suspect that hitting a price point and a market date, something not unique to Asian manufacturers, does far more damage than any regional corporate culture. Money spent on the Tizen OS, beyond something that works well enough to sell, makes Samsung no more money and gets funded accordingly (up-front and afterward to fix the mess).

      • That would certainly explain the "quality" of Microsoft products.
        • by rtb61 ( 674572 )

          To be fair, the Samsung OS comes, sort of free with the device, all they can see is Android. M$ well it comes out crap on purpose so they can sell it again and again, only this time more secure and more stable and more reliable versus prior products original release, the new wrinkle is of course far more privacy invasive and they are now selling you. The next big thing will of course be the Google vs Apple vs M$ VPN wars (M$ is kind of screwed right from the outset, impossible for them to sell privacy now,

    • by Anonymous Coward

      This has nothing to do with Asian, but with EVERY corporate culture, Microsoft, apple had the same problem, they just had to get their shit together after many many years of criticisms, and outrage from their customers...
      Also, stupid statements like "worst code he's ever see" only makes me know that such "expert" has not seen much code actually.
      More than half OS projects on GitHub are a stinking pile of shit, If they let me see that Tizen code, I can show at least a 100 projects with demonstrably consistent

      • by gweihir ( 88907 )

        Also, stupid statements like "worst code he's ever see" only makes me know that such "expert" has not seen much code actually.
        More than half OS projects on GitHub are a stinking pile of shit, If they let me see that Tizen code, I can show at least a 100 projects with demonstrably consistent worst code.

        While I sort-of agree to that, keep in mind that a security expert that understands security _and_ can code and read code with a reasonable level of expertise is already part of a small elite of the field. Yes, it is that bad.

      • by nnull ( 1148259 )
        Partially. From someone that buys equipment, I can tell you Asian manufacturers have little to no written manuals, procedures, maintenance programs, real lack of any real control diagrams and just plain hard to communicate because they really don't care about you once you buy their equipment. I constantly have their sale guys visit my place and attempt to try to convince me how much cheaper it will be if I buy their stuff. They sell to clients that are too dumb to realize their machine actually costs them m
    • corporate culture? bullshit, it is poor engineering/training practises. too many developers think they understand security because they are "good" developers, the reality is unless you are specifically trained in secure development practises then chances are you suck at secure coding.
    • Asian? Does this apply to the corporate culture overseeing code writing in the Bangalore office, the one in Noida, or the one in Delhi? http://www.samsung.com/in/abou... [samsung.com]
    • Asian corporate culture seems to get in the way of cranking-out good code

      It does nothing of the sort. There's plenty good code from various Asian countries (most of which have very varied corporate culture by the way).

      Just nothing good from Samsung. But then I'm not surprised either. Samsung seem to be fantastic at bogging down their hardware with their code. Their TVs are the only ones with quad core processors and still the longest to actually start when you turn them on. The majority of exploits seem to come on them. And I won't ever forget their attempts at coding their own

  • We now know where Samsung falls on the H-1B question.

  • A major multinational corporation is pushing cut-rate garbage?

    Maybe if the outcry is loud enough, Samsung will either fix it or abandon it.

    They built the crap in the first place, so it's clear they won't bother without some outside pressure.

  • As opposed to known zero-day vulnerabilities?
    • by Anonymous Coward

      You joke, but it's true. I can guarantee someone on that team knew this code had a vulnerability and we're ignored.

      • I didn't RTFA, but is Tizen still using Enlightenment? There's a great Daily WTF about that code which, unfortunately, doesn't scratch the surface of what it does dangerously wrong. If it does, I'd be very surprised at only 40 zero-days.
  • Not surprised (Score:5, Interesting)

    by gman003 ( 1693318 ) on Tuesday April 04, 2017 @07:14PM (#54174445)

    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.

    • Similar experience (Score:5, Informative)

      by Ecuador ( 740021 ) on Tuesday April 04, 2017 @08:00PM (#54174757) Homepage

      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 [thedailywtf.com] an educational article about the EFL libraries you get to use when designing native Tizen apps.

      • by TheRaven64 ( 641858 ) on Wednesday April 05, 2017 @05:34AM (#54176427) Journal
        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.

    • 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,

      Moblin (which Intel put as much effort into ripping out all the non-intel support from as doing anything else) begat Meego (which was never usable) which begat Tizen. It would be shocking if it weren't a complete clusterfuck.

  • Tizen has escaped extensive scrutiny from the security community, probably because it's not widely used on phones yet.

    "Yet" - and now "never will be" - we hope.

  • by Opportunist ( 166417 ) on Tuesday April 04, 2017 @07:25PM (#54174529)

    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.

    • by Snotnose ( 212196 ) on Tuesday April 04, 2017 @09:11PM (#54175061)

      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.

      I beg to differ. I've been an embedded software engineer since the early 80s. In 2000 I got a contract from the guy who owned the George Foreman Grill. He wanted an appliance that would mount to the underside of kitchen cabinets, have internet, CD/DVD playback, HiFi quality sound, and connect to a recipe database via 802.11. One of the first things we worried about was security. 802.11 was new back then, nobody really knew how it would work out. The screen would fold down so the user could watch the videos.
      Security came up in every meeting. We knew about it, understood the risks, and didn't know what the hell to do but knew we needed to try.

      Project crashed and burned because he wanted to sell it for $999.95, and we couldn't get the BOM under $1k.

      Every project I've worked on since has had security as a high priority. Lessee, what have I done since then? Um, cellphone base station, cellphone games, electronic ticketing system (take a ticket, now serving #32, you have #38), automated IC testing, muxing MPEG2 streams from multiple satellites into a custom stream, cellphones. Every one of these security has been a top issue.

      • Security was a top issue in the electronic ticketing system? Did they think someone was going to research and exploit some 0-day just to cut in line?
    • 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.

      Please don't lump everything "embedded" under one big banner. We've been hooking "embedded" systems to the internet for the best part of 20+ years now. There's always been a requirement to consider security.

    • by phorm ( 591458 )

      I've always been of the mind that low-resource situations are often *better* for security. If you have a very tight, resource-conservative ecosphere, then there's no reason it can't also be a very tight security-conscious ecosphere. When you start throwing massive pools of memory etc resources, then a lot of people just assume that they'll never hit on limits, so you end up with situations where - instead of doing things to allocate and check sane amounts of memory - you just end up with high limits "hey, l

      • That's less a problem than cutting corners when it comes to sanity checks due to timing or program memory constraints.

        • by phorm ( 591458 )

          True enough, but one would hope that on any "official" modules or API's this stuff isn't done or gets cleaned out.

  • by Hall ( 962 ) on Tuesday April 04, 2017 @07:29PM (#54174565)

    Going way to this site's "nerd" days, people should be familiar with the window-manager-then-a-desktop-environment-under-development-for-a-decade-and-a-half called Enlightenment. It's main developer - Rasterman - worked at Samsung and had a lot to do with this OS. I don't know if he's still involved or not but I haven't heard anything about this OS since he mentioned it years ago.

    • He still works there but AFAIK he is just responsible for features/performance of the UI toolkit stuff. I don't think OS-level security is really in his jurisdiction.

  • "Tizen OS is the worst code I've ever seen"

    "Challenge accepted!" - Microsoft, Mozilla, tons of app store (cr)apps, several bloated antivirus companies ...

    • by Anonymous Coward
      yeah...no you are just mod point whoring. Microsoft and Mozilla have security bugs but they actually have good coding practises and both educate developers on secure coding practises. If anything they are some of the better examples of secure coding practises, doesn't make them perfect but they certainly would not be listed as some of the worst. bloat also doesn't indicate bad security code.
      • I'm stuck at the karma cap - I don't do mod point whoring. The fact is, when code is so slow and bloated, and keeps grabbing more and more ram, and becomes less and less responsive, you don't have to be a security researcher to know the code behind it is shit compared to competitors. You don't have to be a researcher at all to know the code is shit.
    • "Tizen OS is the worst code I've ever seen"

      "Challenge accepted!" - Microsoft, Mozilla, tons of app store (cr)apps, several bloated antivirus companies ...

      Anything that isn't Open Source, would rise to the challenge. When you work as a consultant and see real world production code, you can't sleep well at night.

  • No one could be that incompetent, I figure such vulnerabilities are baked-in from the outset under the direction of the state security apparatus.
    • Mod parent up. I too had a short-liven interest in Tizen development....until I read the above article. Not to mention that the SDK was unstable, with limited instructions, and didn't work well on a RPi either.
    • by gweihir ( 88907 )

      Well, looks like a lot of wheels have been reinvented really badly here. The sign of utterly incompetent engineering and utterly incompetent management that does not know how to identify and hire good engineers and then let them work.

      • The sign of utterly incompetent engineering and utterly incompetent management that does not know how to identify and hire good engineers and then let them work.

        Doesn't this describe most tech companies these days? The open-plan office is proof of incompetent management.

    • by Megane ( 129182 )
      I wanted to emphasize this. This is not new to regular visitors to TDWTF. Enlightenment, which Tizen is based on, is horrible. Fundamentally horrible, as in at the very core of its API, its basic object type is a typedef to void*. So everything you call expects to be passed void pointer references to objects. Which of course will accept any kind of pointer, no matter where it came from.

      The Ravenous Bugblatter Beast of Tizen is a mind-bogglingly stupid codebase. It has almost no capacity for Enlightenment and is therefore surprised by virtually everything that happens to it. Here is an example of how stupid it is: it thinks that if you can't see its pointer types, it can't see you.

      Its behaviour would be quite endearing if it wasn't spoilt by this one thing: it is the most violently crappy codebase in the Galaxy. A void*, a void*, a void*.

    • Yeah, the first thing I though when reading the story was:

      "SPANK SPANK SPANK! Naughty programmer!"

      (a Tizen error code)

  • Watch Samsung sue said researcher.. Gotta keep those liars err lawyers busy ya know...

  • One can only wonder if there are large reveneus in selling separate, compiled accesses to China, USA, Russia and Israel, among others.
  • How can he say such rubbish as a scientist. Has he seen all code of everything? What are his metrics? Don't get me wrong. The Tizen code could be one of the worst code there is. This is a fair hypothesis, but then you have to provide proof. At least some metrics on implementation errors, complexity, patterns etc.

    • How can he say such rubbish as a scientist. Has he seen all code of everything?

      Your post is the stupidest I've read today. I'm not claiming to have read them all (though I doubt it would change if I did).

      • by prefec2 ( 875483 )

        It is nice that you are giving any details to your conclusion. I thought we do not want to indulge in bullshit based on feelings and rather use evidence to come to conclusions. For a summary (even on /.) it is necessary to give a little more than just a "biggest rubbish ever"-claim. If he found flaws he could have provided something like: We found 100 security flaws in the code in 1000 LOC c-code.

    • He found 40 Zero Days, and you actually posted that comment? If I find 40 design flaws in a car engine would you argue that the car could still be awesome because I didn't evaluate the rest of the car?
      • No, he's claiming that your conclusion is wrong because you didn't evaluate every other car in the world, even if your claim was only based on the ones you've seen.

        Set theory's clearly not his thing.

  • When it comes to making it explosive, one way or another, you can rely on Samsung.

What is research but a blind date with knowledge? -- Will Harvey

Working...