Planet

Where is your tech passion?

Postby Dan Langille via Dan Langille's Other Diary »

You like tech. You know you like it. Do you know what part of tech you are most passionate about? I credit a Google employee for the following idea. It was told to me while I was at the FreeBSD Foundation booth at GHC 2016. The following is a relatively cheap project you can do [...]
Top

The Tale of Pythonia

Postby Michał Górny via Michał Górny »

Developers, gather round for I am about to tell thee a story. A story of a far away kingdom, great kings and their affairs. No dragons included.

With special dedication to William L. Thomson Jr.



Once upon a time, in a far away kingdom of Gentoo there was a small state called Pythonia. The state was widely known throughout the land for the manufacture of Python packages.

The state of Pythonia was ruled by Arfruvro the Magnificent. He was recognized as a great authority in the world of Python. Furthermore, he was doing a great deal of work himself, not leaving much to do for his fellow citizens. He had two weaknesses, though: he was an idealist, and he wanted Python packages to be perfect.

Arfruvro frequently changed the design of Python packages manufactured by his state to follow the best practices in the art. Frequently came to the neighbouring states edicts from Pythonia telling their citizens that the Python package design is changing and their own packages need to be changed in 6 or 12 months, or just new packages that broke everything. So did neighbouring states complain to Pythonia, yet Arfruvro did not heed their wishes.

One day, Arfruvro re-issued yet another broken set of Python packages. The uproar was so great that the King Flamessio of the Empowered State of Qualassia decided to invade Pythonia. He removed Arfruvro from the throne and caused him to flee the state. Then, he let the citizens of Pythonia elect a new king.

The new king was a fair and just ruler. However, he stayed in the shadow of his predecessor. The state was no longer able to keep up with the established standards, and the quality and quantity of Python packages decreased. When the progress demanded reforms, nobody in the whole kingdom was capable of doing them. In fact, nobody really knew how all the machinery worked.

At this point, you may think that the state of Pythonia would have surely fallen without Arfruvro. However, it eventually rose again. The old directions were abandoned and major reforms were done. Many have complained that the Python packages are changing again. However, today the state is shining once again. Many citizens are working together, and many of them have the knowledge to lead the state if necessary.

The moral of this story is: it does not matter how great deal of work you did if it is not self-sustainable. What matters is what you leave after you. Arfruvro did great deal of work but Pythonia fell into decay when he left. Today Pythonia is no longer dependent on a single person.

Disclaimer: the characters and events in this story are fictional. Any resemblance between the characters in this story and any persons is purely coincidental.
Top

Who is Anna-Senpai, the Mirai Worm Author?

Postby BrianKrebs via Krebs on Security »

On September 22, 2016, this site was forced offline for nearly four days after it was hit with “Mirai,” a malware strain that enslaves poorly secured Internet of Things (IoT) devices like wireless routers and security cameras into a botnet for use in large cyberattacks. Roughly a week after that assault, the individual(s) who launched that attack — using the name “Anna-Senpai” — released the source code for Mirai, spawning dozens of copycat attack armies online.

After months of digging, KrebsOnSecurity is now confident to have uncovered Anna-Senpai’s real-life identity, and the identity of at least one co-conspirator who helped to write and modify the malware.

Mirai co-author Anna-Senpai leaked the source code for Mirai on Sept. 30, 2016.
Before we go further, a few disclosures are probably in order. First, this is easily the longest story I’ve ever written on this blog. It’s lengthy because I wanted to walk readers through my process of discovery, which has taken months to unravel. The details help in understanding the financial motivations behind Mirai and the botnet wars that preceded it. Also, I realize there are a great many names to keep track of as you read this post, so I’ve included a glossary.

The story you’re reading now is the result of hundreds of hours of research.  At times, I was desperately seeking the missing link between seemingly unrelated people and events; sometimes I was inundated with huge amounts of information — much of it intentionally false or misleading — and left to search for kernels of truth hidden among the dross.  If you’ve ever wondered why it seems that so few Internet criminals are brought to justice, I can tell you that the sheer amount of persistence and investigative resources required to piece together who’s done what to whom (and why) in the online era is tremendous.

As noted in previous KrebsOnSecurity articles, botnets like Mirai are used to knock individuals, businesses, governmental agencies, and non-profits offline on a daily basis. These so-called “distributed denial-of-service (DDoS) attacks are digital sieges in which an attacker causes thousands of hacked systems to hit a target with so much junk traffic that it falls over and remains unreachable by legitimate visitors. While DDoS attacks typically target a single Web site or Internet host, they often result in widespread collateral Internet disruption.

A great deal of DDoS activity on the Internet originates from so-called ‘booter/stresser’ services, which are essentially DDoS-for-hire services which allow even unsophisticated users to launch high-impact attacks.  And as we will see, the incessant competition for profits in the blatantly illegal DDoS-for-hire industry can lead those involved down some very strange paths, indeed.

THE FIRST CLUES

The first clues to Anna-Senpai’s identity didn’t become clear until I understood that Mirai was just the latest incarnation of an IoT botnet family that has been in development and relatively broad use for nearly three years.

Earlier this summer, my site was hit with several huge attacks from a collection of hacked IoT systems compromised by a family of botnet code that served as a precursor to Mirai. The malware went by several names, including “Bashlite,” “Gafgyt,” “Qbot,” “Remaiten,” and “Torlus.”

All of these related IoT botnet varieties infect new systems in a fashion similar to other well-known Internet worms — propagating from one infected host to another. And like those earlier Internet worms, sometimes the Internet scanning these systems perform to identify other candidates for inclusion into the botnet is so aggressive that it constitutes an unintended DDoS on the very home routers, Web cameras and DVRs that the bot code is trying to subvert and recruit into the botnet. This kind of self-defeating behavior will be familiar to those who recall the original Morris Worm, NIMDA, CODE RED, Welchia, Blaster and SQL Slammer disruptions of yesteryear.

Infected IoT devices constantly scan the Web for other IoT things to compromise, wriggling into devices that are protected by little more than insecure factory-default settings and passwords. The infected devices are then forced to participate in DDoS attacks (ironically, many of the devices most commonly infected by Mirai and similar IoT worms are security cameras).

Mirai’s ancestors had so many names because each name corresponded to a variant that included new improvements over time. In 2014, a group of Internet hooligans operating under the banner “lelddos” very publicly used the code to launch large, sustained attacks that knocked many Web sites offline.

The most frequent target of the lelddos gang were Web servers used to host Minecraft, a wildly popular computer game sold by Microsoft that can be played from any device and on any Internet connection.

The object of Minecraft is to run around and build stuff, block by large pixelated block. That may sound simplistic and boring, but an impressive number of people positively adore this game – particularly pre-teen males. Microsoft has sold more than a 100 million copies of Minecraft, and at any given time there are over a million people playing it online. Players can build their own worlds, or visit a myriad other blocky realms by logging on to their favorite Minecraft server to play with friends.

Image: Minecraft.net
A large, successful Minecraft server with more than a thousand players logging on each day can easily earn the server’s owners upwards of $50,000 per month, mainly from players renting space on the server to build their Minecraft worlds, and purchasing in-game items and special abilities.

Perhaps unsurprisingly, the top-earning Minecraft servers eventually attracted the attention of ne’er-do-wells and extortionists like the lelddos gang. Lelddos would launch a huge DDoS attack against a Minecraft server, knowing that the targeted Minecraft server owner was likely losing thousands of dollars for each day his gaming channel remained offline.

Adding urgency to the ordeal, many of the targeted server’s loyal customers would soon find other Minecraft servers to patronize if they could not get their Minecraft fix at the usual online spot.

Robert Coelho is vice president of ProxyPipe, Inc., a San Francisco company that specializes in protecting Minecraft servers from attacks.

“The Minecraft industry is so competitive,” Coelho said. “If you’re a player, and your favorite Minecraft server gets knocked offline, you can switch to another server. But for the server operators, it’s all about maximizing the number of players and running a large, powerful server. The more players you can hold on the server, the more money you make. But if you go down, you start to lose Minecraft players very fast — maybe for good.”

In June 2014, ProxyPipe was hit with a 300 gigabit per second DDoS attack launched by lelddos, which had a penchant for publicly taunting its victims on Twitter just as it began launching DDoS assaults at the taunted.

The hacker group “lelddos” tweeted at its victims before launching huge DDoS attacks against them.
At the time, ProxyPipe was buying DDoS protection from Reston, Va. -based security giant Verisign. In a quarterly report published in 2014, Verisign called the attack the largest it had ever seen, although it didn’t name ProxyPipe in the report – referring to it only as a customer in the media and entertainment business.

Verisign said the 2014 attack was launched by a botnet of more than 100,000 servers running on SuperMicro IPMI boards. Days before the huge attack on ProxyPipe, a security researcher published information about a vulnerability in the SuperMicro devices that could allow them to be remotely hacked and commandeered for these sorts of attacks.

THE CENTRALITY OF PROTRAF

Coelho recalled that in mid-2015 his company’s Minecraft customers began coming under attack from a botnet made up of IoT devices infected with Qbot. He said the attacks were directly preceded by a threat made by a then-17-year-old Christopher “CJ” Sculti, Jr., the owner and sole employee of a competing DDoS protection company called Datawagon.

Datawagon also courted Minecraft servers as customers, and its servers were hosted on Internet space claimed by yet another Minecraft-focused DDoS protection provider — ProTraf Solutions.

Christopher “CJ” Sculti, Jr.
According to Coelho, ProTraf was trying to woo many of his biggest Minecraft server customers away from ProxyPipe. Coelho said in mid-2015, Sculti reached out to him on Skype and said he was getting ready to disable Coelho’s Skype account. At the time, an exploit for a software weakness in Skype was being traded online, and this exploit could be used to remotely and instantaneously disable any Skype account.

Sure enough, Coelho recalled, his Skype account and two others used by co-workers were shut off just minutes after that threat, effectively severing a main artery of support for ProxyPipe’s customers – many of whom were accustomed to communicating with ProxyPipe via Skype.

“CJ messaged me about five minutes before the DDoS started, saying he was going to disable my skype,” Coelho said. “The scary thing about when this happens is you don’t know if your Skype account has been hacked and under control of someone else or if it just got disabled.”

Once ProxyPipe’s Skype accounts were disabled, the company’s servers were hit with a massive, constantly changing DDoS attack that disrupted ProxyPipe’s service to its Minecraft server customers. Coelho said within a few days of the attack, many of ProxyPipe’s most lucrative Minecraft servers had moved over to servers run protected by ProTraf Solutions.

“In 2015, the ProTraf guys hit us offline tons, so a lot of our customers moved over to them,” Coelho said. “We told our customers that we knew [ProTraf] were the ones doing it, but some of the customers didn’t care and moved over to ProTraf anyway because they were losing money from being down.”

I found Coelho’s story fascinating because it eerily echoed the events leading up to my Sept. 2016 record 620 Gbps attack. I, too, was contacted via Skype by Sculti — on two occasions. The first was on July 7, 2015, when Sculti reached out apropos of nothing to brag about scanning the Internet for IoT devices running default usernames and passwords, saying he had uploaded some kind of program to more than a quarter-million systems that his scans found.

Here’s a snippet of that conversation:

July 7, 2015:

21:37 CJ: http://krebsonsecurity.com/2015/06/crooks-use-hacked-routers-to-aid-cyberheists/
21:37 CJ: vulnerable routers are a HUGE issue
21:37 CJ: a few months ago
21:37 CJ: I scanned the internet with a few sets of defualt logins
21:37 CJ: for telnet
21:37 CJ: and I was able to upload and execute a binary
21:38 CJ: on 250k devices
21:38 CJ: most of which were routers
21:38 Brian Krebs: o_0

The second time I heard from Sculti on Skype was Sept. 20, 2016 — the day of my 620 Gbps attack. Sculti was angry over a story I’d just published that mentioned his name, and he began rather saltily maligning the reputation of a source and friend who had helped me with that story.

Indignant on behalf of my source and annoyed at Sculti’s rant, I simply blocked his Skype account from communicating with mine and went on with my day. Just minutes after that conversation, however, my Skype account was flooded with thousands of contact requests from compromised or junk Skype accounts, making it virtually impossible to use the software for making phone calls or instant messaging.

Six hours after that Sept. 20 conversation with Sculti, the huge 620 Gbps DDoS attack commenced on this site.

WHO IS LELDDOS?

Coelho said he believes the main members of lelddos gang were Sculti and the owners of ProTraf. Asked why he was so sure of this, he recounted a large lelddos attack in early 2015 against ProxyPipe that coincided with a scam in which large tracts of Internet address space were temporarily stolen from the company.

According to ProxyPipe, a swath of Internet addresses was hijacked from the company by FastReturn, a cloud hosting firm. Dyn, a company that closely tracks which blocks of Internet addresses are assigned to which organizations, confirmed the timing of the Internet address hijack that Coelho described.

A few months after that attack, the owner of FastReturn — a young man named Ammar Zuberi — went to work as a software developer for ProTraf. In the process, Zuberi transferred the majority of Internet addresses assigned to FastReturn over to ProTraf.

Zuberi told KrebsOnSecurity that he was not involved with lelddos, but he acknowledged that he did hijack ProxyPipe’s Internet address space before moving over to ProTraf.

“I was stupid and new to this entire thing and it was interesting to me how insecure the underlying ecosystem of the Internet was,” Zuberi said. “I just kept pushing the envelope to see how far I could get with that, I guess. I eventually realized though and got away from it, although that’s not really much of a justification.”

According to Zuberi, CJ Sculti Jr. was a member of lelddos, as were the two co-owners of ProTraf. This is interesting because not long after the September 2016 Mirai attack took this site offline, several sources who specialize in lurking on cybercrime forums shared information suggesting that the principal author of Bashlite/Qbot was a ProTraf employee: A 19-year-old computer whiz from Washington, Penn. named Josiah White.

White’s profile on LinkedIn lists him as an “enterprise DDoS mitigation expert” at ProTraf, but for years he was better known to those in the hacker community under the alias “LiteSpeed.”

LiteSpeed is the screen name White used on Hackforums[dot]net – a sprawling English-language marketplace where mostly young, low-skilled hackers can buy and sell cybercrime tools and stolen goods with ease. Until very recently, Hackforums also was the definitive place to buy and sell DDoS-for-hire services.

I contacted White to find out if the rumors about his authorship of Qbot/Bashlite were true. White acknowledged that he had written some of Qbot/Bashlite’s components — including the code segment that the malware uses to spread the infection to new machines. But White said he never intended for his code to be sold and traded online.

White claims that a onetime friend and Hackforums member nicknamed “Vyp0r” betrayed his trust and forced him to publish the code online by threatening to post White’s personal details online and to “swat” his home. Swatting is a potentially deadly hoax in which an attacker calls in a fake hostage situation or bomb threat at a residence or business with the intention of sending a team of heavily-armed police officers to the target’s address.

“Most of the stuff that I had wrote was for friends, but as I later realized, things on HF [Hackforums] tend to not remain private,” White wrote in an instant message to KrebsOnSecurity. “Eventually I learned they were reselling them in under-the-table deals, and so I just released everything to stop that. I made some mistakes when I was younger, and I realize that, but I’m trying to set my path straight and move on.”

WHO IS PARAS JHA?



White’s employer ProTraf Solutions has only one other employee – 20-year-old President Paras Jha, from Fanwood, NJ. On his LinkedIn profile, Jha states that “Paras is a passionate entrepreneur driven by the want to create.” The profile continues:

“Highly self-motivated, in 7th grade he began to teach himself to program in a variety of languages. Today, his skillset for software development includes C#, Java, Golang, C, C++, PHP, x86 ASM, not to mention web ‘browser languages’ such as Javascript and HTML/CSS.”

Jha’s LinkedIn page also shows that he has extensive experience running Minecraft servers, and that for several years he worked for Minetime, one of the most popular Minecraft servers at the time.

After first reading Jha’s LinkedIn resume, I was haunted by the nagging feeling that I’d seen this rather unique combination of computer language skills somewhere else online. Then it dawned on me: The mix of programming skills that Jha listed in his LinkedIn profile is remarkably similar to the skills listed on Hackforums by none other than Mirai’s author — Anna-Senpai.

Prior to leaking the Mirai source code on HackForums at the end of September 2016, the majority of Anna-Senpai’s posts on Hackforums were meant to taunt other hackers on the forum who were using Qbot to build DDoS attack armies.

The best example of this is a thread posted to Hackforums on July 10, 2016 titled “Killing All Telnets,” in which Anna-Senpai boldly warns forum members that the malicious code powering his botnet contains a particularly effective “bot killer” designed to remove Qbot from infected IoT devices and to prevent systems infected with his malware from ever being reinfected with Qbot again.

Anna-Senpai warns Qbot users that his new worm (relatively unknown by its name “Mirai” at the time) was capable of killing off IoT devices infected with Qbot.
Initially, forum members dismissed Anna’s threats as idle taunts, but as the thread continues for page after page we can see from other forum members that his bot killer is indeed having its intended effect. [Oddly enough, it’s very common for the authors of botnet code to include patching routines to protect their newly-enslaved bots from being compromised by other miscreants.  Just like in any other market, there is a high degree of competition between cybercrooks who are constantly seeking to add more zombies to their DDoS armies, and they often resort to unorthodox tactics to knock out the competition.  As we’ll see, this kind of internecine warfare is a major element in this story.]

“When the owner of this botnet wrote a July 2016 Hackforums thread named ‘Killing all Telnets’, he was right,” wrote Allison Nixon and Pierre Lamy, threat researchers for New York City-based security firm Flashpoint. “Our intelligence around that time reflected a massive shift away from the traditional gafgyt infection patterns and towards a different pattern that refused to properly execute on analysts’ machines. This new species choked out all the others.”

It wasn’t until after I’d spoken with Jha’s business partner Josiah White that I began re-reading every one of Anna-Senpai’s several dozen posts to Hackforums. The one that made Jha’s programming skills seem familiar came on July 12, 2016 — a week after posting his “Killing All Telnets” discussion thread — when Anna-Senpai contributed to a Hackforums thread started by a hacker group calling itself “Nightmare.”

Such groups or hacker cliques are common on Hackforums, and forum members can apply for membership by stating their skills and answering a few questions. Anna-Senpai posted his application for membership into this thread among dozens of others, describing himself thusly:

Age: 18+

Location and Languages Spoken: English

Which of the aforementioned categories describe you the best?: Programmer / Development

What do you Specialize in? (List only): Systems programming / general low level languages (C + ASM)

Why should we choose you over other applicants?: I have 8 years of development under my belt, and I’m very familiar with programming in a variety of languages, including ASM, C, Go, Java, C#, and PHP. I like to use this knowledge for personal gain.”

The Hackforums post shows Jha and Anna-Senpai have the exact same programming skills. Additionally, according to an analysis of Mirai by security firm Incapsula, the malicious software used to control a botnet powered by Mirai is coded in Go (a.k.a. “Golang”), a somewhat esoteric programming language developed by Google in 2007 that saw a surge in popularity in 2016. Incapsula also said the malcode that gets installed on IoT bots is coded in C.



DREADIS[NOT]COOL

I began to dig deeper into Paras Jha’s history and footprint online, and discovered that his father in October 2013 registered a vanity domain for his son, parasjha.info. That site is no longer online, but a historic version of it cached by the indispensable Internet Archive includes a resume of Jha’s early work with various popular Minecraft servers. Here’s a autobiographical snippet from parasjha.info:

“My passion is to utilize my skills in programming and drawing to develop entertaining games and software for the online game ‘Minecraft. Someday, I plan to start my own enterprise focused on the gaming industry targeted towards game consoles and the mobile platform. To further my ideas and help the gaming community, I have released some of my code to open source projects on websites centered on public coding under the handle dreadiscool.”

A Google search for this rather unique username “dreadiscool” turns up accounts by the same name at dozens of forums dedicated to computer programming and Minecraft. In many of those accounts, the owner is clearly frustrated by incessant DDoS attacks targeting his Minecraft servers, and appears eager for advice on how best to counter the assaults.

From Dreadiscool’s various online postings, it seems clear that at some point Jha decided it might be more profitable and less frustrating to defend Minecraft servers from DDoS attacks, as opposed to trying to maintain the servers themselves.

“My experience in dealing with DDoS attacks led me to start a server hosting company focused on providing solutions to clients to mitigate such attacks,” Jha wrote on his vanity site.

Some of the more recent Dreadiscool posts date to November 2016, and many of those posts are lengthy explanations of highly technical subjects. The tone of voice in these posts is far more confident and even condescending than the Dreadiscool from years earlier, covering a range of subjects from programming to DDoS attacks.

Dreadiscool’s account on Spigot Minecraft forum since 2013 includes some interesting characters photoshopped into this image.
For example, Dreadiscool has been an active member of the Minecraft forum spigotmc.org since 2013. This user’s avatar (pictured above) on spigotmc.org is an altered image taken from the 1994 Quentin Tarantino cult hit “Pulp Fiction,” specifically from a scene in which the gangster characters Jules and Vincent are pointing their pistols in the same direction. However, the heads of both actors have been digitally altered to include someone else’s faces.

Pasted over the head of John Travolta’s character (left) is a real-life picture of Vyp0r — the Hackforums nickname of the guy that ProTraf’s Josiah White said threatened him into releasing the source code for Bashlite. On the shoulders of Samuel L. Jackson’s body is the face of Tucker Preston, co-founder of BackConnect Security — a competing DDoS mitigation provider that also has a history of hijacking Internet address ranges from other providers.

Pictured below and to the left of Travolta and Jackson’s characters — seated on the bed behind them — is “Yamada,” a Japanese animation (“anime”) character featured in the anime movie B Gata H Hei.

Turns out, there is a Dreadiscool user on MyAnimeList.net, a site where members proudly list the various anime films they have watched. Dreadiscool says B Gata H Kei is one of nine anime film series he has watched. Among the other eight? The anime series Mirai Nikki, from which the Mirai malware derives its name.

Dreadiscool’s Reddit profile also is very interesting, and most of the recent posts there relate to major DDoS attacks going on at the time, including a series of DDoS attacks on Rutgers University. More on Rutgers later.

A CHAT WITH ANNA-SENPAI

At around the same time as the record 620 Gbps attack on KrebsOnSecurity, French Web hosting giant OVH suffered an even larger attack — launched by the very same Mirai botnet used to attack this site. Although this fact has been widely reported in the news media, the reason for the OVH attack may not be so well known.

According to a tweet from OVH founder and chief technology officer Octave Klaba, the target of that massive attack also was a Minecraft server (although Klaba mistakenly called the target “mindcraft servers” in his tweet).

A tweet from OVH founder and CTO, stating the intended target of Sept. 2016 Mirai DDoS on his company.
Turns out, in the days following the attack on this site and on OVH, Anna-Sempai had trained his Mirai botnet on Coelho’s ProxyPipe, completely knocking his DDoS mitigation service offline for the better part of a day and causing problems for many popular Minecraft servers.

Unable to obtain more bandwidth and unwilling to sign an expensive annual contract with a third-party DDoS mitigation firm, Coelho turned to the only other option available to get out from under the attack: Filing abuse complaints with the Internet hosting firms that were responsible for providing connectivity to the control server used to orchestrate the activities of the Mirai botnet.

“We did it because we had no other options, and because all of our customers were offline,” Coelho said. “Even though no other DDoS mitigation company was able to defend against these attacks [from Mirai], we still needed to defend against it because our customers were starting to move to other providers that attracted fewer attacks.”

After scouring a list of Internet addresses tied to bots used in the attack, Coelho said he was able to trace the control server for the Mirai botnet back to a hosting provider in Ukraine. That company — BlazingFast[dot]io — has a reputation for hosting botnet control networks (even now, Spamhaus is reporting an IoT botnet controller running out of BlazingFast since Jan. 17, 2017).

Getting no love from BlazingFast, Coelho said he escalated his complaint to Voxility, a company that was providing DDoS protection to BlazingFast at the time.

“Voxility acknowledged the presence of the control server, and said they null-routed [removed] it, but they didn’t,” Coelho said. “They basically lied to us and didn’t reply to any other emails.”

Undeterred, Coelho said he then emailed the ISP that was upstream of BlazingFast, but received little help from that company or the next ISP further upstream. Coelho said the fifth ISP upstream of BlazingFast, however — Internet provider Telia Sonera — confirmed his report, and promptly had the Mirai botnet’s control server killed.

As a result, many of the systems infected with Mirai could no longer connect to the botnet’s control servers, drastically reducing the botnet’s overall firepower.

“The action by Telia cut the size of the attacks launched by the botnet down to 80 Gbps,” well within the range of ProxyPipe’s in-house DDoS mitigation capabilities, Coelho said.

Incredibly, on Sept. 28, Anna-Senpai himself would reach out to Coelho via Skype. Coelho shared a copy of that chat conversation with KrebsOnSecurity. The log shows that Anna correctly guessed ProxyPipe was responsible for the abuse complaints that kneecapped Mirai. Anna-Senpai said he guessed ProxyPipe was responsible after reading a comment on a KrebsOnSecurity blog post from a reader who shared the same username as Coelho’s business partner.

In the following chat, Coelho is using the Skype nickname “katie.onis.”

[10:23:08 AM] live:anna-senpai: ^
[10:26:08 AM] katie.onis: hi there.
[10:26:52 AM] katie.onis: How can I help you?
[10:28:06 AM] live:anna-senpai: hi
[10:28:45 AM] live:anna-senpai: you know i had my suspicions, but this one was proof

http://imgur.com/E1yFJOp [this is a benign/safe link to a screenshot of some comments on KrebsOnSecurity.com]

[10:28:59 AM] live:anna-senpai: don’t get me wrong, im not even mad, it was pretty funny actually. nobody has ever done that to my c2 [Mirai “command and control” server]
[10:29:25 AM] live:anna-senpai: (goldmedal)
[10:29:29 AM] katie.onis: ah you’re mistaken, that’s not us.
[10:29:33 AM] katie.onis: but we know who it is
[10:29:42 AM] live:anna-senpai: eric / 9gigs
[10:29:47 AM] katie.onis: no, 9gigs is erik
[10:29:48 AM] katie.onis: not eric
[10:29:53 AM] katie.onis: different people
[10:30:09 AM] live:anna-senpai: oh?
[10:30:17 AM] katie.onis: yep
[10:30:39 AM] live:anna-senpai: is he someone related to you guys?
[10:30:44 AM] katie.onis: not related to us, we just know him
[10:30:50 AM] katie.onis: anyway, we’re not interested in any harm, we simply don’t want attacks against us.
[10:31:16 AM] live:anna-senpai: yeah i figured, i added you because i wanted to tip my hat if that was actually you lol
[10:31:24 AM] katie.onis: we didn’t make that dumb post
[10:31:26 AM] katie.onis: if that is what you are asking
[10:31:30 AM] katie.onis: but yes, we were involved in doing that.
[10:31:47 AM] live:anna-senpai: so you got it nulled, but some other eric is claiming credit for it?
[10:31:52 AM] katie.onis: seems so.
[10:31:52 AM] live:anna-senpai: eric with a c
[10:31:56 AM] live:anna-senpai: lol
[10:32:17 AM] live:anna-senpai: can’t say im surprised, tons of people take credit for things that they didn’t do if nobody else takes credit for
[10:32:24 AM] katie.onis: we’re not interested in taking credit
[10:32:30 AM] katie.onis: we just wanted the attacks to get smaller

NOTICE AND TAKEDOWN

One reason Anna-Senpai may have been enamored of Coelho’s approach to taking down Mirai is that Anna-Senpai had spent the previous month doing exactly the same thing to criminals running IoT botnets powered by Mirai’s top rival — Qbot.

A month before this chat between Coelho and Anna-Senpai, Anna is busy sending abuse complaints to various hosting firms, warning them that they are hosting huge IoT botnet control channels that needed to be shut down. This was clearly just part of an extended campaign by the Mirai botmasters to eliminate other IoT-based DDoS botnets that might compete for the same pool of vulnerable IoT devices. Anna confirmed this in his chat with Coelho:

[10:50:36 AM] live:anna-senpai: i have good killer so nobody else can assemble a large net
[10:50:53 AM] live:anna-senpai: i monitor the devices to see for any new threats
[10:51:33 AM] live:anna-senpai: and when i find any new host, i get them taken down

The ISPs or hosting providers that received abuse complaints from Anna-Senpai were all encouraged to reply to the email address ogmemes123123@gmail.com for questions and/or confirmation of the takedown. ISPs that declined to act promptly on Anna-Senpai’s Qbot email complaints soon found themselves on the receiving end of enormous DDoS attacks from Mirai.

Francisco Dias, owner of hosting provider Frantech, found out firsthand what it would cost to ignore one of Anna’s abuse reports. In mid-September 2016, Francisco accidentally got into an Internet fight with Anna-Senpai.  The Mirai botmaster was using the nickname “jorgemichaels” at the time — and Jorgemichaels was talking trash on LowEndTalk.com, a discussion forum for vendors of low-costing hosting.

Specifically, Jorgemichaels takes Francisco to task publicly on the forum for ignoring one of his Qbot abuse complaints. Francisco tells Jorgemichaels to file a complaint with the police if it’s so urgent. Jorgemichaels tells Francisco to shut up, and when Francisco is silent for a while Jorgemichaels gloats that Francisco learned his place. Francisco explains his further silence on the thread by saying he’s busy supporting customers, to which Jorgemichaels replies, “Sounds like you just got a lot more customers to help. Don’t mess with the underworld francisco or it will harm your business.”

Shortly thereafter, Frantech is systematically knocked offline after being attacked by Mirai. Below is a fascinating snippet from a private conversation between Francisco and Anna-Senpai/Jorgemichaels, in which Francisco kills the reported Qbot control server to make Anna/Jorgemichaels call off the attack.

Using the nickname “jorgemichaels” on LowEndTalk, Anna-Senpai reaches out to Francisco Dias after Dias ignores Anna’s abuse complaint. Francisco agrees to kill the Qbot control server only after being walloped with Mirai.
Back to the chat between Anna-Senpai and Coelho at the end of Sept 2016.  Anna-Senpai tells Coelho that the attacks against ProxyPipe aren’t personal; they’re just business. Anna says he has been renting out “net spots” — sizable chunks of his Mirai botnet — to other hackers who use them in their own attacks for pre-arranged periods of time.

By way of example, Anna brags that as he and Coelho are speaking, the owners of a large Minecraft server were paying him to launch a crippling DDoS against Hypixel, currently the world’s most popular Minecraft server. KrebsOnSecurity confirmed with Hypixel that they were indeed under a massive attack from Mirai between Sept. 27 and 30.

[12:24:00 PM] live:anna-senpai: right now i just have a script sitting there hitting them for 45s every 20 minutes
[12:24:09 PM] live:anna-senpai: enough to drop all players and make them rage

Coelho told KrebsOnSecurity that the on-again, off-again attack DDoS method that Anna described using against Hypixel was designed not just to cost Hypixel money. The purpose of that attack method, he said, was to aggravate and annoy Hypixel’s customers so much that they might take their business to a competing Minecraft server.

“It’s not just about taking it down, it’s about making everyone who is playing on that server crazy mad,” Coelho explained. “If you launch the attack every 20 minutes for a short period of time, you basically give the players just enough time to get back on the server and involved in another game before they’re disconnected again.”

Anna-Senpai told Coelho that paying customers also were the reason for the 620 Gbps attack on KrebsOnSecurity. Two weeks prior to that attack, I published the results of a months-long investigation revealing that “vDOS” — one of the largest and longest-running DDoS-for-hire services — had been hacked, exposing details about the services owners and customers.

The story noted that vDOS earned its proprietors more than $600,000 and was being run by two 18-year-old Israeli men who went by the hacker aliases “applej4ck” and “p1st0”. Hours after that piece ran, Israeli authorities arrested both men, and vDOS — which had been in operation for four years — was shuttered for good.

[10:47:42 AM] live:anna-senpai: i sell net spots, starting at $5k a week
[10:47:50 AM] live:anna-senpai: and one client was upset about applejack arrest
[10:48:01 AM] live:anna-senpai: so while i was gone he was sitting on them for hours with gre and ack
[10:48:14 AM] live:anna-senpai: when i came back i was like oh fuck
[10:48:16 AM] live:anna-senpai: and whitelisted the prefix
[10:48:24 AM] live:anna-senpai: but then krebs tweeted that akamai is kicking them off
[10:48:31 AM] live:anna-senpai: fuck me
[10:48:43 AM] live:anna-senpai: he was a cool guy too, i like his article

[SIDE NOTE: If true, it’s ironic that someone would hire Anna-Senpai to attack my site in retribution for the vDOS story. That’s because the firepower behind applej4ck’s vDOS service was generated in large part by a botnet of IoT systems infected with a Qbot variant — the very same botnet strain that Anna-Senpai and Mirai were busy killing and erasing from the Internet.]

Coelho told KrebsOnSecurity that if his side of the conversation reads like he was being too conciliatory to his assailant, that’s because he was wary of giving Anna a reason to launch another monster attack against ProxyPipe. After all, Coelho said, the Mirai attacks on ProxyPipe caused many customers to switch to other Minecraft servers, and Coelho estimates the attack cost the company between $400,000 and $500,000.

Nevertheless, about halfway through the chat Coelho gently confronts Anna on the consequences of his actions.

[10:54:17 AM] katie.onis: People have a genuine reason to be unhappy though about large attacks like this
[10:54:27 AM] live:anna-senpai: yeah
[10:54:32 AM] katie.onis: There’s really nothing anyone can do lol
[10:54:36 AM] live:anna-senpai:
[10:54:38 AM] katie.onis: And it does affect their lives
[10:55:10 AM] live:anna-senpai: well, i stopped caring about other people a long time ago
[10:55:18 AM] live:anna-senpai: my life experience has always been get fucked over or fuck someone else over
[10:55:52 AM] katie.onis: My experience with [ProxyPipe] thus far has been
[10:55:54 AM] katie.onis: Do nothing bad to anyone
[10:55:58 AM] katie.onis: And still get screwed over
[10:55:59 AM] katie.onis: Haha

The two even discussed anime after Anna-Senpai guessed that Coelho might be a fan of the genre. Anna-Senpai says he watched the anime series “Gate,” a reference to the above-mentioned B Gata H Hei that Dreadiscool included in the list of anime film series he’s watched. Anna also confirms that the name for his bot malware was derived from the anime series Mirai Nikki.

[5:25:12 PM] live:anna-senpai: i rewatched mirai nikki recently
[5:25:22 PM] live:anna-senpai: (it was the reason i named my bot mirai lol)

DREADISCOOL = ANNA = JHA?

Coelho said when Anna-Senpai first reached out to him on Skype, he had no clue about the hacker’s real-life identity. But a few weeks after that chat conversation with Anna-Senpai, Coelho’s business partner (the Eric referenced in the first chat segment above) said he noticed that some of the code in Mirai looked awfully similar to code that Dreadiscool had posted to his Github account.

“He started to come to the conclusion that maybe Anna was Paras,” Coelho said. “He gave me a lot of ideas, and after I did my own investigation I decided he was probably right.”

Coelho said he’s known Paras Jha for more than four years, having met him online when Jha was working for Minetime — which ProxyPipe was protecting from DDoS attacks at the time.

“We talked a lot back then and we used to program a lot of projects together,” Coelho said. “He’s really good at programming, but back then he wasn’t. He was a little bit behind, and I was teaching him most everything.”

According to Coelho, as Jha became more confident in his coding skills, he also grew more arrogant, belittling others online who didn’t have as firm a grasp on subjects such as programming and DDoS mitigation.

“He likes to be recognized for his knowledge, being praised and having other people recognize that,” Coelho said of Jha. “He brags too much, basically.”

Coelho said not long after Minetime was hit by a DDoS extortion attack in 2013, Paras joined Hackforums and fairly soon after stopped responding to his online messages.

“He just kind of dropped off the face of the earth entirely,” he said. “When he started going on Hackforums, I didn’t know him anymore. He became a different person.”

Coelho said he doesn’t believe his old friend wished him harm, and that Jha was probably pressured into attacking ProxyPipe.

“In my opinion he’s still a kid, in that he gets peer-pressured a lot,” Coelho said. “If he didn’t [launch the attack] not only would he feel super excluded, but these people wouldn’t be his friends anymore, they could out him and screw him over. I think he was pretty much in a really bad position with the people he got involved with.”

THE RUTGERS DDOS ATTACKS

On Dec. 16, security vendor Digital Shadows presented a Webinar that focused on clues about the Mirai author’s real life identity. According to their analysis, before the Mirai author was known as Anna-Senpai on Hackforums, he used the nickname “Ogmemes123123” (this also was the alias of the Skype username that contacted Coelho), and the email address ogmemes123123@gmail.com (recall this is the same email address Anna-Senpai used in his alerts to various hosting firms about the urgent need to take down Qbot control servers hosted on their networks).

Digital Shadows noted that the Mirai author appears to have used another nickname: “OG_Richard_Stallman,” a likely reference to the founder of the Free Software Foundation. The ogmemes123123@gmail.com account was used to register a Facebook account in the name of OG_Richard Stallman.

That Facebook account states that OG_Richard_Stallman began studying computer engineering at New Brunswick, NJ-based Rutgers University in 2015.

As it happens, Paras Jha is a student at Rutgers University. This is especially notable because Rutgers has been dealing with a series of DDoS attacks on its network since the fall semester of 2015 — more than a half dozen incidents in all. With each DDoS, the attacker would taunt the university in online posts and media interviews, encouraging the school to spend the money to purchase some kind of DDoS mitigation service.



Using the nicknames  “og_richard_stallman,” “exfocus” and “ogexfocus,” the person who attacked Rutgers more than a half-dozen times took to Reddit and Twitter to claim credit for the attacks. Exfocus even created his own “Ask Me Anything” interview on Reddit to discuss the Rutgers attacks.

Exfocus also gave an interview to a New Jersey-based blogger, claiming he got paid $500 an hour to DDoS the university with as many as 170,000 bots. Here are a few snippets from that interview, in which he blames the attacks on a “client” who is renting his botnet:

Are you for real? Why would you do an interview with us if you’re getting paid?

Normally I don’t show myself, but the entity paying me has something against the school. They want me to “make a splash”.

Why do you have a twitter account where you publically broadcast patronizing messages. Are you worried that this increases the risk of things getting back to you?

Public twitter is on clients request. The client hates the school for whatever reason. They told me to say generic things like that I hate the bus system and etc.

Have you ever attacked RU before?

During freshman registration the client requested it also – he didn’t want any publicity then though.

What are your plans for the future in terms of DDOSing and attacking the Rutgers cyber infrastructure?

When I stop getting paid – I’ll stop DDosing lol. I’m hoping that RU will sign on some ddos mitigation provider. I get paid extra if that happens.

At some point you said you were at the Livingston student center – outside of Sbarro. In this interview you said that you aren’t affiliated directly with Rutgers, did you lie then?

Yes”

An online search for the Gmail address used by Anna-Senpai and OG_Richard_Stallman turns up a Pastebin post from July 1, 2016, in which an anonymous Pastebin user creates a “dox” of OG_Richard_Stallman. Doxing refers to the act of publishing someone’s personal information online and/or connecting an online alias to a real life identity.

The dox said OG_Richard_Stallman was connected to an address and phone number of an individual living in Turkey. But this is almost certainly a fake dox intended to confuse cybercrime investigators. Here’s why:

A Google search shows that this same address and phone number showed up in another dox on Pastebin from almost three years earlier — June 2013 — intended to expose or confuse the identity of a Hackforums user known as LiteSpeed. Recall that LiteSpeed is the same alias that ProTraf’s Josiah White acknowledged using on Hackforums.

EXTORTION ATTEMPTS BY OG_RICHARD_STALLMAN

This OG_Richard_Stallman identity is connected to Anna-Senpai by another person we’ve heard from already: Francisco Dias, whose Frantech ISP was attacked by Anna-Senpai and Mirai in mid-September. Francisco told KrebsOnSecurity that in early August 2016 he began receiving extortion emails from a Gmail address associated with a OG_Richard_Stallman.

“This guy using the Richard Stallman name added me on Skype and basically said ‘I’m going to knock all of your [Internet addresses] offline until you pay me’,” Dias recalled. “He told me the up front cost to stop the attack was 10 bitcoins [~USD $5,000 at the time], and if I didn’t pay within four hours after the attack started the fee would double to 20 bitcoins.”

Dias said he didn’t pay the demand and eventually OG_Richard_Stallman called off the attack. But he said for a while the attacks were powerful enough to cause problems for Frantech’s Internet provider.

“He was hitting us so hard with Mirai that he was dropping large parts of Hurricane Electric and causing problems at their Los Angeles point of presence,” Dias said. “I basically threw everything behind [DDoS mitigation provider] Voxility, and eventually Stallman buggered off.”

The OG_Richard_Stallman identity also was tied to similar extortion attacks at the beginning of August against one hosting firm that had briefly been one of ProTraf’s customers in 2016. The company declined to be quoted on the record, but said it stopped doing business with Protraf in mid-2016 because they were unhappy with the quality of service.

The Internet provider said not long after that it received an extortion demand from the “OG_Richard_Stallman” character for $5,000 in Bitcoin to avoid a DDoS attack. One of the company’s researchers contacted the extortionist via the ogmemes123123@gmail.com address supplied in the email, but posing as someone who wished to hire some DDoS services.

OG_Richard_Stallman told the researcher that he could guarantee 350 Gbps of attack traffic and that the target would go down or the customer would receive a full refund. The price for the attack? USD $100 worth of Bitcoin for every five minutes of attack time.

My source at the hosting company said his employer declined to pay the demand, and subsequently got hit with an attack from Mirai that clocked in at more than 300 Gbps.

“Clearly, the attacker is very technical, as they attacked every single [Internet address] within the subnet, and after we brought up protection, he started attacking upstream router interfaces,” the source said on condition of anonymity.

Asked who they thought might be responsible for the attacks, my source said his employer immediately suspected ProTraf. That’s because the Mirai attack also targeted the Internet address for the company’s home page, but that Internet address was hidden by DDoS mitigation firm Cloudflare. However, ProTraf knew about the secret address from its previous work with the company, the source explained.

“We believe it’s Protraf’s staff or someone related to Protraf,” my source said.

A source at an Internet provider agreed to share information about an extortion demand his company received from OG_Richard_Stallman in August 2016. Here he is contacting the Stallman character directly and pretending to be someone interested in renting a botnet. Notice the source brazenly said he wanted to DDoS ProTraf.

DDOS CONFESSIONS

After months of gathering information about the apparent authors of Mirai, I heard from Ammar Zuberi, once a co-worker of ProTraf President Paras Jha.

Zuberi told KrebsOnSecurity that Jha admitted he was responsible for both Mirai and the Rutgers DDoS attacks. Zuberi said when he visited Jha at his Rutgers University dorm in October 2015, Paras bragged to him about launching the DDoS attacks against Rutgers.

“He was laughing and bragging about how he was going to get a security guy at the school fired, and how they raised school fees because of him,” Zuberi recalled.  “He didn’t really say why he did it, but I think he was just sort of experimenting with how far he could go with these attacks.”

Zuberi said he didn’t realize how far Jha had gone with his DDoS attacks until he confronted him about it late last year. Zuberi said he was on his way to see his grandmother in Arizona at the end of November 2016, and he had a layover in New York. So he contacted Jha and arranged to spend the night at Jha’s home in Fanwood, New Jersey.

As I noted in Spreading the DDoS Disease and Selling the Cure, Anna-Senpai leaked the Mirai code on a domain name (santasbigcandycane[dot]cx) that was registered via Namecentral, an extremely obscure domain name registrar which had previously been used to register fewer than three dozen other domains over a three-year period.

According to Zuberi, only five people knew about the existence of Namecentral: himself, CJ Sculti, Paras Jha, Josiah White and Namecentral’s owner Jesse Wu (19-year-old Wu features prominently in the DDoS Disease story linked in the previous paragraph).

“When I saw that the Mirai code had been leaked on that domain at Namecentral, I straight up asked Paras at that point, ‘Was this you?,’ and he smiled and said yep,” Zuberi recalled. “Then he told me he’d recently heard from an FBI agent who was investigating Mirai, and he showed me some text messages between him and the agent. He was pretty proud of himself, and was bragging that he led the FBI on a wild goose chase.”

Zuberi said he hasn’t been in contact with Jha since visiting his home in November. Zuberi said he believes Jha wrote most of the code that Mirai uses to control the individual bot-infected IoT devices, since it was written in Golang and Jha’s partner White didn’t code well in this language. Zuberi said he thought White’s role was mainly in developing the spreading code used to infect new IoT devices with Mirai, since that was written in C — a language White excelled at.

In the time since most of the above occurred, the Internet address ranges previously occupied by ProTraf have been withdrawn. ProxyPipe’s Coelho said it could be that the ProTraf simply ran out of money.

ProTraf’s Josiah White explained the disappearance of ProTraf’s Internet space as part of an effort to reboot the company.

“We [are] in the process of restructuring and refocusing what we are doing,” White told KrebsOnSecurity.

Jha did not respond to requests for comment.

Update: Jan. 19, 10:51 a.m. ET: Jha responded to my request for comment. His first comment about this story was that I erred in citing the proper anime film listed on one of the dreadiscool profiles mentioned above. When asked directly about his alleged involvement with Mirai, Jha said he did not write Mirai and was not involved in attacking Rutgers.

“The first time it happened, I was a freshman, and living in the dorms,” Jha said. “At the culmination of the attacks near the end of the year, I was without internet for almost a week, along with the rest of the student body. I couldn’t register for classes, and had a host of issues dealing with it. This semester and the previous semester were the reasons I moved to commute, because of these problems that I frankly don’t have time to deal with.”

Jha said Zuberi did spend the night at his house last year but he denied admitting anything to Zuberi. He acknowledged hearing from an FBI agent investigating Mirai, but said “no comment” when asked if he’d heard from that FBI agent since then.

“I don’t think there are enough facts to definitively point the finger at me,” Jha said. “Besides this article, I was pretty much a nobody. No history of doing this kind of stuff, nothing that points to any kind of sociopathic behavior. Which is what the author is, a sociopath.”

Original story:

Rutgers University did not respond to requests for comment.

FBI officials could not be immediately reached for comment.

A copy of the entire chat between Anna-Senpai and ProxyPipe’s Coelho is available here.
Top

ansible: Timeout waiting for privilege escalation prompt

Postby Dan Langille via Dan Langille's Other Diary »

I was doing some work in a remote location with a laggy connection to home. I was running ansible and kept encountering these errors: fatal: [pg01]: FAILED! => {"failed": true, "msg": "Timeout (12s) waiting for privilege escalation prompt: "} Rerunning the script would encounter the same error in a different part of the script. After [...]
Top

<sys-libs/zlib-1.2.11 – possible data corruption

Postby ago via agostino's blog »

I don’t know if a news will be sent. A possibile data corruption was found on zlib 1.2.10.
Please update your zlib to 1.2.11 and make sure you restart all services that are linked to zlib (a reboot may be an easy way).

Gentoo bug:
https://bugs.gentoo.org/show_bug.cgi?id=605888

Upstream bug:
https://github.com/madler/zlib/issues/198

Upstream commit:
https://github.com/madler/zlib/commit/4c7c90768308587884fab6159d93a4695a5ab1f0</a
Top

jasper: invalid memory read in jas_matrix_asl (jas_seq.c)

Postby ago via agostino's blog »

Description:
jasper is an open-source initiative to provide a free software-based reference implementation of the codec specified in the JPEG-2000 Part-1 standard.

Another round of fuzzing shows that a crafted image causes an invalid memory read.

The complete ASan output:

# imginfo -f $FILE
==26941==ERROR: AddressSanitizer: SEGV on unknown address 0x62c80000a400 (pc 0x7f28c74e48ee bp 0x7ffcececdb70 sp 0x7ffcececdaf0 T0)
==26941==The signal is caused by a READ memory access.
    #0 0x7f28c74e48ed in jas_matrix_asl /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/base/jas_seq.c:376:11
    #1 0x7f28c7545f0e in jpc_dec_tiledecode /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:1107:6
    #2 0x7f28c7536cdf in jpc_dec_process_sod /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:658:7
    #3 0x7f28c75406b3 in jpc_dec_decode /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:425:10
    #4 0x7f28c75406b3 in jpc_decode /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:262
    #5 0x7f28c74a2b84 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/base/jas_image.c:444:16
    #6 0x509eed in main /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/appl/imginfo.c:219:16
    #7 0x7f28c65aa61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #8 0x419978 in _init (/usr/bin/imginfo+0x419978)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/base/jas_seq.c:376:11 in jas_matrix_asl
==26941==ABORTING
Affected version:
1.900.27

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00053-jasper-invalidread-jas_matrix_asl

Timeline:
2016-11-20: bug discovered and reported upstream
2017-01-16: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

jasper: invalid memory read in jas_matrix_asl (jas_seq.c)

Top

jasper: invalid memory read in jpc_undo_roi (jpc_dec.c)

Postby ago via agostino's blog »

Description:
jasper is an open-source initiative to provide a free software-based reference implementation of the codec specified in the JPEG-2000 Part-1 standard.

Another round of fuzzing shows that a crafted image causes an invalid memory read.

The complete ASan output:

# imginfo -f $FILE
==22872==ERROR: AddressSanitizer: SEGV on unknown address 0x7f8a4a950800 (pc 0x7f8e4a543b93 bp 0x7ffe29bfdcd0 sp 0x7ffe29bfdb80 T0)
==22872==The signal is caused by a READ memory access.
    #0 0x7f8e4a543b92 in jpc_undo_roi /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:1925:10
    #1 0x7f8e4a543b92 in jpc_dec_tiledecode /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:1104
    #2 0x7f8e4a534cdf in jpc_dec_process_sod /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:658:7
    #3 0x7f8e4a53e6b3 in jpc_dec_decode /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:425:10
    #4 0x7f8e4a53e6b3 in jpc_decode /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:262
    #5 0x7f8e4a4a0b84 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/base/jas_image.c:444:16
    #6 0x509eed in main /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/appl/imginfo.c:219:16
    #7 0x7f8e495a861f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #8 0x419978 in _init (/usr/bin/imginfo+0x419978)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:1925:10 in jpc_undo_roi
==22872==ABORTING
Affected version:
1.900.27

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00054-jasper-invalidread-jpc_undo_roi

Timeline:
2016-11-20: bug discovered and reported upstream
2017-01-16: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

jasper: invalid memory read in jpc_undo_roi (jpc_dec.c)

Top

jasper: invalid memory write in dec_clnpass (jpc_t1dec.c)

Postby ago via agostino's blog »

Description:
jasper is an open-source initiative to provide a free software-based reference implementation of the codec specified in the JPEG-2000 Part-1 standard.

Another round of fuzzing shows that a crafted image causes an invalid memory write.

The complete ASan output:

# imginfo -f $FILE
==24746==ERROR: AddressSanitizer: SEGV on unknown address 0x7ef94fe46c88 (pc 0x7efd4faa510d bp 0x7ffde2235af0 sp 0x7ffde2235900 T0)
==24746==The signal is caused by a WRITE memory access.
    #0 0x7efd4faa510c in dec_clnpass /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_t1dec.c:869:4
    #1 0x7efd4faa510c in jpc_dec_decodecblk /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_t1dec.c:283
    #2 0x7efd4fa9ef89 in jpc_dec_decodecblks /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_t1dec.c:177:11
    #3 0x7efd4fa394f1 in jpc_dec_tiledecode /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:1085:6
    #4 0x7efd4fa2acdf in jpc_dec_process_sod /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:658:7
    #5 0x7efd4fa346b3 in jpc_dec_decode /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:425:10
    #6 0x7efd4fa346b3 in jpc_decode /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_dec.c:262
    #7 0x7efd4f996b84 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/base/jas_image.c:444:16
    #8 0x509eed in main /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/appl/imginfo.c:219:16
    #9 0x7efd4ea9e61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #10 0x419978 in _init (/usr/bin/imginfo+0x419978)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/media-libs/jasper-1.900.27/work/jasper-1.900.27/src/libjasper/jpc/jpc_t1dec.c:869:4 in dec_clnpass
==24746==ABORTING
Affected version:
1.900.27

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00055-jasper-invalidwrite-dec_clnpass

Timeline:
2016-11-20: bug discovered and reported upstream
2017-01-16: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

jasper: invalid memory write in dec_clnpass (jpc_t1dec.c)

Top

jasper: multiple crashes with UBSAN

Postby ago via agostino's blog »

Description:
jasper is an open-source initiative to provide a free software-based reference implementation of the codec specified in the JPEG-2000 Part-1 standard.

With the undefined behavior sanitizer enabled, jasper crashes showing some left shift and some signed integer overflow.

Affected version / Tested on:
1.900.17
Fixed version:
N/A
Commit fix:
N/A
Reproducer:
https://github.com/asarubbo/poc/blob/master/00017-jasper-leftshift-jas_math_h
Relevant part of the stacktrace:

# imginfo -f $FILE
/tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/include/jasper/jas_math.h:156:11: runtime error: left shift of negative value -185
#################################################

Affected version / Tested on:
1.900.17
Fixed version:
N/A
Commit fix:
N/A
Reproducer:
https://github.com/asarubbo/poc/blob/master/00018-jasper-signedintoverflow-jpc_dec_c
Relevant part of the stacktrace:

# imginfo -f $FILE
/tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_dec.c:1838:9: runtime error: signed integer overflow: -64356352 * 6359082673847140352 cannot be represented in type 'long'
#################################################

Affected version / Tested on:
1.900.17
Fixed version:
N/A
Commit fix:
N/A
Reproducer:
https://github.com/asarubbo/poc/blob/master/00019-jasper-leftshift-jpc_dec_c
Relevant part of the stacktrace:

# imginfo -f $FILE
/tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_dec.c:1819:40: runtime error: shift exponent 117 is too large for 64-bit type 'jpc_fix_t' (aka 'long')
#################################################

Affected version / Tested on:
1.900.17
Fixed version:
N/A
Commit fix:
N/A
Reproducer:
https://github.com/asarubbo/poc/blob/master/00022-jasper-signedintoverflow-jpc_tsfb_c
Relevant part of the stacktrace:

# imginfo -f $FILE
/tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_tsfb.c:233:35: runtime error: signed integer overflow: 2013306369 + 251691968 cannot be represented in type 'int'
#################################################

Affected version / Tested on:
1.900.17
Fixed version:
N/A
Commit fix:
N/A
Reproducer:
https://github.com/asarubbo/poc/blob/master/00030-jasper-leftshift-jp2_dec_c
Relevant part of the stacktrace:

# imginfo -f $FILE
/tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jp2/jp2_dec.c:485:49: runtime error: left shift of negative value -26
Credit:
These bugs were discovered by Agostino Sarubbo of Gentoo.

Timeline:
2016-10-28: bug discovered and reported to upstream
2017-01-16: blog post about the issues

Note:
These bugs were found with American Fuzzy Lop.

Permalink:

jasper: multiple crashes with UBSAN

Top

These weeks in vc4 (2017-01-16): NEON acceleration of tiling

Postby Eric Anholt via anholt's lj »

Last week I was on vacation, but the week before that I did some more work on figuring out Intel's Mesa CI system, and Mark Janes has started working on some better documentation for it.  I now understand better how the setup is going to work, but haven't made much progress on actually getting a master running yet.

More fun, though, was finally taking a look at optimizing the tiled texture load/store code.  This got started with Patrick Walton tweeting a link to a blog post on clever math for implementing texture tiling, given a couple of assumptions.

As with all GPUs these days, VC4 swizzles textures into a tiled layout so that when a cacheline is loaded from memory, it will cover nearby pixels in the Y direction as well as X, so that you are more likely to get cache hits for your neighboring pixels in drawing.  And the tiling tends to be multiple levels, so that nearby cachelines are also nearby on the screen, reducing DRAM access latency.

For small textures on VC4, we have a single level of tiling: 4x4@32bpp blocks ("utiles") of raster order data, themselves arranged in up to a 4x4 block, and this mode is called LT.  Once things go over that size, we go to T tiling, where we call a 4x4 LT block a subtile, and arrange subtiles either clockwise or counterclockwise order within a 2x2 block (a tile, which at this point is now 1kb of data), and tiles themselves are arranged left-to-right, then right-to-left, then left-to-right again.

The first thing I did was implement the blog post's clever math for LT textures.  One of the nice features of the math trick is that it means I can do partial utile updates finally, because it skips around in the GPU's address space based on the CPU-side pixel coordinate instead of trying to go through GPU address space to update a 4x4 utile at a time.  The downside of doing things this way is that jumping around in GPU address space means that our writes are unlikely to benefit from write combining, which is usually important for getting full write performance to GPU memory.  It turned out, though, that the math was so much more efficient than what I was doing that it was still a win.

However, I found out that the clever math made reads slower.  The problem is that, because we're write-combined, reads are uncached -- each load is a separate bus transaction to main memory.  Switching from my old utile-at-a-time load using memcpy to the new code meant that instead of doing 4 loads using NEON to grab a row at a time, we were now doing 16 loads of 32 bits at a time, for what added up to a 30% performance hit.

Reads *shouldn't* be something that people do much, except that we still have some software fallbacks in X on VC4 ("core" unantialiased text rendering, for example, which I need to write the GLSL 1.20 shaders for), which involve doing a read/modify/write cycle on a texture.  My first attempt at fixing the regression was just adding back a fast path that operates on a utile at a time if things are nicely utile-aligned (they generally are).  However, some forced inlining of functions per cpp that I was doing for the unaligned case meant that the glibc memcpy call now got inlined back to being non-NEON, and the "fast" utile code ended up not helping loads.

Relying on details of glibc's implementation (their tradeoff for when to do NEON loads) and of gcc's implementation (when to go from memcpy calls to inlined 32-bits-at-a-time code) seems like a pretty bad idea, so I decided to finally write the NEON acceleration that Eben and I have talked about several times.

My first hope was that I could load a full cacheline with NEON's VLD.  VLD1 only loads up to 1 "quadword" (16 bytes) at a time, so that doesn't seem like much help.  VLD4 can load 64 bytes like we want, but it also turns AOS data into SOA in the process, and there's no corresponding "SOA-back-to-AOS store 8 or 16 bytes at a time" like we need to do to get things back into the CPU's strided representation.  I tried VLD4+VST4 into a temporary, then doing my old untiling path on the cached temporary, but that still left me a few percent slower on loads than not doing any of this work at all.

Finally, I hit on using the VLDM instruction.  It seems to be intended for stack loads/stores, but we can also use it to get 64 bytes of data in from memory untouched into NEON registers, and then I can use 4 (32bpp) or 8 (8 or 16bpp) VST1s to store it to the CPU side.  With this, we get a 208.256% +/- 7.07029% (n=10) improvement to GetTexImage performance at 1024x1024.  Doing the same NEON code for stores gave a 41.2371% +/- 3.52799% (n=10) improvement, probably mostly due to not calling into memcpy and having it go through its size/alignment-based memcpy path choosing process.

I'm not yet hitting full memory bandwidth, but this should be a noticeable improvement to X, and it'll probably help my piglit test suite runtime as well.  Hopefully I'll get the code polished up and landed next week when I get back from LCA.
Top

Schon wieder ein Jahr älter.

Postby bed via Zockertown: Nerten News »

Also dieses Blog, meine ich.

Am 13.Januar 2005 bin ich mit Serendipity online gegangen.

Das sind 12 Jahre bloggen mit derselben Software! Entweder bin ich einfach zu faul, bzw. zu alt geworden, oder dieses Stück Software ist einfach geil.

Und übrigens, in den 12 Jahren 1 EINe! eingeschleppte Malware, nicht 38099494 Trillionen wie bei Joomla, hach, das gibt wieder einen Shitstorm.

Ist mir aber egal, weil Page Rank (gibt es den noch?) und Reichweite sind mir vollkommen Wumpe.

Ich bin mir bewusst, dass die Ära der Blogs zuende geht, Video Blogs sind in, man kann prima beim Auspacken von Päckchen zusehen, stundenlang irgendwas erklärt bekommen, was man auch in 5 Sätzen hätte schreiben können. Deshalb ist es nicht verwunderlich, wenn hier kaum mehr kommentiert wird, außer dem aggressivem Marketing-Zwangs-Kommentaren, die bisher aber hier automatisch verhindert werden. 

Für mich wichtiger ist: ich habe hier meinen Zusatzspeicher, mein externes Memory und ich freue mich einfach darüber, dass mir hier niemand irgendwelche Vorschriften macht und ich keine IP-Adressen logge, bzw. kurzfristig anonymisiere, kein Google fucking sense,  Partnerprogramme, whatever nutze und trotzdem kein Vermögen fürs hosten ausgeben muss.

Ps: der mit Abstand am meisten kommentierte Artikel ist: http://zockertown.de/s9y/index.php?/archives/681-dosbox-XCOM3-Apocalypse.html

Und Kommentare im Verhältnis zum Spam:

Rated comments
Name Homepage Email
Referer Comment
Valid Spam Valid Spam Valid Spam Valid Spam Valid Spam Valid Spam
26 11535 18 50622 14 1634 26 73322 25 1621 26 1100
pps: das Tag Linux habe ich hier nicht gesetzt, weil ich auf den Planet.Ubuntu hiermit nicht erscheinen will.
Top

Adobe, Microsoft Push Critical Security Fixes

Postby BrianKrebs via Krebs on Security »

Adobe and Microsoft on Tuesday each released security updates for software installed on hundreds of millions of devices. Adobe issued an update for Flash Player and for Acrobat/Reader. Microsoft released just four updates to plug some 15 security holes in Windows and related software.

Microsoft’s batch includes updates for Windows, Office and Microsoft Edge (Redmond’s replacement for Internet Explorer). Also interesting is that January 2017 is the last month Microsoft plans to publish individual bulletins for each patch. From now on, some of the data points currently in the individual updates will be lumped into a “Security Updates Guide” published with each Patch Tuesday.

This change mirrors a shift in the way Microsoft is deploying updates. Last year Microsoft stopped making individual security updates available for home users, giving those users instead a single monthly security rollup that includes all available security updates.

Windows users and anyone else with Flash installed will need to make sure that Adobe Flash Player is updated (or suitably bludgeoned, more on that in a bit). Adobe’s Flash update addresses 13 flaws in the widely-installed browser plugin. The patch brings Flash to v. 24.0.0.194 for Windows, Mac and Linux users alike.

If you have Flash installed, you should update, hobble or remove Flash as soon as possible. To see which version of Flash your browser may have installed, check out this page. But the smartest option is probably to ditch the program once and for all and significantly increase the security of your system in the process. An extremely powerful and buggy program that binds itself to the browser, Flash is a favorite target of attackers and malware. For some ideas about how to hobble or do without Flash (as well as slightly less radical solutions) check out A Month Without Adobe Flash Player.

If you choose to keep and update Flash, please do it today. The most recent versions of Flash should be available from the Flash home page. Windows users who browse the Web with anything other than Internet Explorer may need to apply this patch twice, once with IE and again using the alternative browser (Firefox, Opera, e.g.).

Chrome and IE should auto-install the latest Flash version on browser restart (users may need to manually check for updates in and/or restart the browser to get the latest Flash version). My version of Chrome says it’s the latest one (55.0.2883.87) but the Chrome Releases blog says the latest stable version — 55.0.2883.105 includes the Flash fixes (among other security fixes for Chrome), which isn’t yet being offered. Adobe’s Web site tells me my Flash version is 24.0.0.186 (not the latest).

When in doubt with Chrome, click the vertical three dot icon to the right of the URL bar, select “Help,” then “About Chrome”: If there is an update available, Chrome should install it then. In either case, be sure to restart the browser after installing an update (if it doesn’t do that for you).

As ever, if you experience any issues applying these updates, please don’t hesitate to leave a note about the issue in the comments below. You might help someone else who’s having the same problem!
Top

Extortionists Wipe Thousands of Databases, Victims Who Pay Up Get Stiffed

Postby BrianKrebs via Krebs on Security »

Tens of thousands of personal and possibly proprietary databases that were left accessible to the public online have just been wiped from the Internet, replaced with ransom notes demanding payment for the return of the files. Adding insult to injury, it appears that virtually none of the victims who have paid the ransom have gotten their files back because multiple fraudsters are now wise to the extortion attempts and are competing to replace each other’s ransom notes.

At the eye of this developing data destruction maelstrom is an online database platform called MongoDBTens of thousands of organizations use MongoDB to store data, but it is easy to misconfigure and leave the database exposed online. If installed on a server with the default settings, for example, MongoDB allows anyone to browse the databases, download them, or even write over them and delete them.

Shodan, a specialized search engine designed to find things that probably won’t be picked up by Google, lists the number of open, remotely accessible MongDB databases available as of Jan. 10, 2017.
This blog has featured several stories over the years about companies accidentally publishing user data via incorrectly configured MongoDB databases. In March 2016, for example, KrebsOnSecurity broke the news that Verizon Enterprise Solutions managed to leak the contact information on some 1.5 million customers because of a publicly accessible MongoDB installation.

Point is, this is a known problem, and almost once a week some security researcher is Tweeting that he’s discovered another huge open MongoDB database. There are simple queries that anyone can run via search engines like Shodan that will point to all of the open MongoDB databases out there at any given time. For example, the latest query via Shodan (see image above) shows that there are more than 52,000 publicly accessible MongoDB databases on the Internet right now. The largest share of open MongoDB databases are here in the United States.

Normally, when one runs a query on Shodan to list all available MongoDB databases, what one gets in return is a list of variously-named databases, and many databases with default filenames like “local.”

But when researcher Victor Gevers ran that same query earlier this week, he noticed that far too many of the database listings returned by the query had names like “readme,” “readnow,” “encrypted” and “readplease.” Inside each of these databases is exactly one file: a database file that includes a contact email address and/or a bitcoin address and a payment demand.

Researcher Niall Merrigan, a solutions architect for French consulting giant Cap Gemini, has been working with Gevers to help victims on his personal time, and to help maintain a public document that’s live-chronicling the damage from the now widespread extortion attack. Merrigan said it seems clear that multiple actors are wise to the scam because if you wait a few minutes after running the Shodan query and then re-run the query, you’ll find the same Internet addresses that showed up in the database listings from the previous query, but you’ll also notice that many now have a different database title and a new ransom note.

Merrigan and Gevers are maintaining a public Google Drive document (read-only) that is tracking the various victims and ransom demands. Merrigan said it appears that at least 29,000 MongoDB databases that were previously published online are now erased. Worse, hardly anyone who’s paid the ransom demands has yet received their files back.

A screen shot of the Google Drive document that Merrigan is maintaining to track the various ransom campaigns. This tab lists victims by industry. As we can see, many have paid the ransom but none have reported receiving their files back.
“It’s like the kidnappers keep delivering the ransom notes, but you don’t know who has the actual original data,” Merrigan said. “That’s why we’re tracking the notes, so that if we see the [databases] are being exfiltrated by the thieves, we can know the guys who should actually get paid if they want to get their data back.”

For now, Merrigan is advising victims not to pay the ransom. He encouraged those inclined to do so anyway to demand “proof of life” from the extortionists — i.e., request that they share one or two of the deleted files to prove that they can restore the entire cache.

Merrigan said the attackers appear to be following the plan of attack. Use Shodan to scan for open MongoDB databases, connect using anonymous access, and then list all available databases. The attacker may or may not download the data before deleting it, leaving in its place a single database file with the extortionists contact and payment info and ransom note.

Merrigan said it’s unclear what prompted this explosion in extortion attacks on MongoDB users, but he suspects someone developed a “method” for extorting others that was either shared, sold or leaked to other ne’er-do-wells, who then began competing to scam each other — leaving victims in the lurch.

“It’s like the early 1800s gold rush in the United States, everyone is just going west at the same time,” Merrigan said. “The problem is, everyone was sold the same map.”

Zach Wikholm, a research developer at New York City-based security firm Flashpoint said he’s confirmed that at least 20,000 databases have been deleted — possibly permanently.

“You’re looking at over 20,000 databases that have gone from being useful to being encrypted and held for ransom,” Wikholm said. “I’m not sure the Internet as a whole has ever experienced anything like this at one time. The fact that we can pull down the number of databases that have been compromised and are still compromised is not a good sign. It means that most victims are unaware what has happened, or they’re not sure how it’s happened or what to do about it.”

Normally, I don’t have great timing, but yesterday’s posts on Immutable Truths About Data Breaches seems almost prescient given this developing attack. Truth 1: “If you connect it to the Internet, someone will try to hack it.” Truth 2: “If what you put on the Internet has value, someone will invest time and effort to steal it.” Truth 3: “Organizations and individuals unwilling to spend a small fraction of what those assets are worth to secure them against cybercrooks can expect to eventually be relieved of said assets.”

H/T to Graham Cluley for a heads-up on this situation.

Update, 1:55 p.m. ET: Clarified the default settings of a MongoDB installation. Also clarified story to note that Gevers discovered the extortion attempts.
Top

Krebs’s Immutable Truths About Data Breaches

Postby BrianKrebs via Krebs on Security »

I’ve had several requests for a fresh blog post to excerpt something that got crammed into the corner of a lengthy story published here Sunday: A list of immutable truths about data breaches, cybersecurity and the consequences of inaction.

Here’s the excerpt requested from yesterday’s story:

“There are some fairly simple, immutable truths that each of us should keep in mind, truths that apply equally to political parties, organizations and corporations alike:

-If you connect it to the Internet, someone will try to hack it.

-If what you put on the Internet has value, someone will invest time and effort to steal it.

-Even if what is stolen does not have immediate value to the thief, he can easily find buyers for it.

-The price he secures for it will almost certainly be a tiny slice of its true worth to the victim.

-Organizations and individuals unwilling to spend a small fraction of what those assets are worth to secure them against cybercrooks can expect to eventually be relieved of said assets.”

They may not be complete, but as a set of truisms these tenets probably will age pretty well. After all, taken as a whole they are practically a model Cybercriminal Code of Ethics, or a cybercrook’s social contract.

Nevertheless, these tenets might be even more powerful if uttered in the voice of the crook himself. That may be more in keeping with the theme of this blog overall, which seeks to explain cybersecurity and cybercrime concepts through the lens of the malicious attacker (often this is a purely economic perspective).

So let’s rifle through this ne’er-do-well’s bag of tricks, tools and tells. Let us borrow from his literary perspective. I imagine a Cybercriminal Code of Ethics might go something like this (again, in the voice of a seasoned crook):

-If you hook it up to the Internet, we’re gonna hack at it.

-If what you put on the Internet is worth anything, one of us is gonna try to steal it.

-Even if we can’t use what we stole, it’s no big deal. There’s no hurry to sell it. Also, we know people.

-We can’t promise to get top dollar for what we took from you, but hey — it’s a buyer’s market. Be glad we didn’t just publish it all online.

-If you can’t or won’t invest a fraction of what your stuff is worth to protect it from the likes of us, don’t worry: You’re our favorite type of customer!

Top

DNI: Putin Led Cyber, Propaganda Effort to Elect Trump, Denigrate Clinton

Postby BrianKrebs via Krebs on Security »

Russian President Vladimir Putin directed a massive propaganda and cyber operation aimed at discrediting Hillary Clinton and getting Donald Trump elected, the top U.S. intelligence agencies said in a remarkable yet unshocking report released on Friday.

Russian President Vladimir Putin tours RT facilities. Image: DNI
The 25-page dossier from the Office of the Director of National Intelligence stopped short of saying the Russians succeeded at influencing the outcome of the election, noting that the report did not attempt to make an assessment on that front. But it makes the case that “Russia’s intelligence services conducted cyber operations against targets associated with the 2016 US presidential election, including targets associated with both major US political parties.”

“We assess with high confidence that Russian military intelligence (General Staff Main Intelligence Directorate or GRU) used the Guccifer 2.0 persona and DCLeaks.com to release US victim data obtained in cyber operations publicly and in exclusives to media outlets and relayed material to WikiLeaks,” the DNI report reads.

The report is a quick and fascinating read. One example: It includes a fairly detailed appendix which concludes that the U.S.-based but Kremlin-financed media outlet RT (formerly Russia Today) is little more than a propaganda machine controlled by Russian intelligence agencies.

“Moscow’s influence campaign followed a Russian messaging strategy that blends covert intelligence operations—such as cyber activity—with overt efforts by Russian Government agencies, state-funded media, third-party intermediaries, and paid social media users or ‘trolls,'” reads the report.

The DNI report is remarkable for several reasons. First, it publicly accuses Russia’s President of trying to meddle with the U.S. election and to hack both political parties. Also, as The New York Times observed, it offers “a virtually unheard-of, real-time revelation by the American intelligence agencies that undermined the legitimacy of the president who is about to direct them.”

However, those who’ve been clamoring for more technical evidence to support a conclusion that Russian intelligence agencies were behind the phishing, malware attacks and email leaks at The Democratic National Committee (DNC) and Clinton campaign likely will be unmoved by this report. Those details will remain safely hidden from public view in the classified version of the report.

Last week, the FBI and Department of Homeland Security issued a joint report (PDF) on some of the malware and Internet resources used in the DNC intrusion. But many experts criticized it as a poorly-written, jumbled collection of threat indicators and digital clues that didn’t all quite lead where they should.

Others were perplexed by the high confidence level the agencies assigned to the findings in their unclassified report, noting that neither the FBI nor DHS examined the DNC hard drives that were compromised in the break-in (that work was done by private security firm Crowdstrike).

Former black-hat hacker turned Wired and Daily Beast contributing editor Kevin Poulsen slammed the FBI/DHS report as “so aimless that it muddies the clear public evidence that Russia hacked the Democratic Party to affect the election, and so wrong it enables the Trump-friendly conspiracy theorists trying to explain away that evidence.”

Granted, trying to reconstruct a digital crime scene absent some of the most important pieces of evidence is a bit like attempting to assemble a jigsaw puzzle with only half of the pieces. But as digital forensics and security expert Jonanthan Zdziarksi noted via Twitter last night, good old fashioned spying and human intelligence seems to have played a bigger role in pinning the DNC hack on the Russians.

“The DNI report subtly implied that more weight was put on our intelligence coming from espionage operations than on cyber warfare,” Zdziarski wrote. “As someone who’s publicly called out the FBI over misleading the public and the court system, I believe the DNI report to be reliable. I also believe @CrowdStrike’s findings to be reliable based on the people there and their experience with threat intelligence.”

Key findings from the DNI report.
My take? Virtually nothing in the DNI report is dispositive of anything in the FBI/DHS report. In other words, the DNI report probably won’t change anyone’s minds. I’m sure that many smart U.S. intelligence analysts spent a great deal of time on this, but none of it was particularly surprising at all: The DNI report describes precisely the kind of cloak and dagger stuff that one might expect the Kremlin to be doing to the United States, day-in and day-out.

What makes these kinds of cyber espionage and propaganda campaigns so worthwhile is that even if the Kremlin cannot always get its favorite candidate elected, Moscow may still consider it a success if it can continuously sow doubt in the minds of Americans about the legitimacy of the U.S. election process and other tenets of democracy.

It’s also exactly the sort of thing the U.S. government has been doing to other countries for decades. In fact, the U.S. has done so as many as 81 times between 1946 and 2000, according to a database amassed by political scientist Dov Levin of Carnegie Mellon University, writes Nina Agrawal for The Los Angeles Times.

Anyone shocked by the Kremlin-funded news station RT in all of this probably never heard of Voice of America, a U.S. government-funded news service that broadcast the American response to Soviet propaganda during the Cold War.

President-elect Trump has publicly mocked American intelligence assessments that Russia meddled with the U.S. election on his behalf, and said recently that he doubts the U.S. government can be certain it was hackers backed by the Russian government who hacked and leaked emails from the DNC.

Mr. Trump issued a statement last night only loosely acknowledging Russian involvement, saying that “while Russia, China, other countries, outside groups and people are consistently trying to break through the cyber institutions, businesses and organizations including the Democrat [sic] National Committee, there was absolutely no effect on the outcome of the election including the fact that there was no tampering whatsoever with the voting machines.”

Trump also has called for a review of the nation’s plans to stop cyberattacks, which he said will be completed within 90 days of his taking office on Jan. 20.

“Whether it is our government, organizations, associations or businesses we need to aggressively combat and stop cyberattacks,” Trump said. “I will appoint a team to give me a plan within 90 days of taking office. The methods, tools and tactics we use to keep America safe should not be a public discussion that will benefit those who seek to do us harm. Two weeks from today I will take the oath of office and America’s safety and security will be my number one priority.”

Time will tell if Mr. Trump’s team can do anything to slow the frequency of data breaches in the United States. But I hope we can all learn from this report. It’s open season out there for sure, but there are some fairly simple, immutable truths that each of us should keep in mind, truths that apply equally to political parties, organizations and corporations alike:

-If you connect it to the Internet, someone will try to hack it.

-If what you put on the Internet has value, someone will invest time and effort to steal it.

-Even if what is stolen does not have immediate value to the thief, he can easily find buyers for it.

-The price he secures for it will almost certainly be a tiny slice of its true worth to the victim.

-Organizations and individuals unwilling to spend a small fraction of what those assets are worth to secure them against cybercrooks can expect to eventually be relieved of said assets.

“We assess Moscow will apply lessons learned from its Putin-ordered campaign aimed at the US presidential election to future influence efforts worldwide, including against US allies and their election processes,” the DNI report concludes.

Yeah, no kidding. The question is: Will political and corporate leaders begin applying those lessons to their own operations, and gird themselves for full-on, 24/7 cyberattacks from every direction, before, during and after each election? How many more examples do we need to understand that maybe we’re really not taking this cybersecurity stuff seriously enough given what’s at stake?

The DNI report is available here (PDF).
Top

DD - der alte Bekannte

Postby bed via Zockertown: Nerten News »

Ich arbeite privat und Beruflich seit mehr als 2 Dekaden mit Unix, da gibt es halt kleine Tools, die einem in Fleisch und Blut übergegangen sind.

dd ist so ein Tool, klar, kennt jeder, der schon ein wenig mit Linux unterwegs ist. Häufig wird es benutzt, um Abbilder auf USB Sticks zu kopieren, blöd ist nur, dass man keinen Fortschritt sieht, man muss sich halt gedulden.

So sieht das ungefähr aus.

dd if=Superlinux.iso of=/dev/sdc bs=8M
Doch es lohnt sich alle paar Versionen mal wieder die Man Pages zu studieren, denn seit der Version 8.24 hat dd den Parameter status um progress erweitert.

Nun ist es bequem möglich, den Fortschritt zu beobachten, mit dem oflag=direct wird die Schreiboperation auch nicht gebuffert, d.h. Wenn dd sagt, es ist fertig, kann man den Stick entfenen und muss nicht erst auf das Ende der Schreiboperation warten.





dd if=Superlinux.iso of=/dev/sdc bs=8M status=progress oflag=direct 
Hinweis: Debian Jessie beinhaltet dd in Version 8.23, dort existiert progress noch nicht.

Noch ein Hinweis, mit etwas Mühe ist es auch in den älteren Versionen den Progress abzufragen, man man von einem anderen Prozess aus den Fortschritt abzufragen



kill -USR1 <prozessnummer des dd>
PS: Ja, ich weiß, mit dd kann man noch viel mehr machen, zum Beispiel Code Conversion, ASCII to EBCDIC oder Byte Order tauschen usw. Zockertown ist keine Lehranstalt, sondern eine Gedankenstütze für den Auto, die zufällig im Web frei verfügbar ist
Top

Stolen Passwords Fuel Cardless ATM Fraud

Postby BrianKrebs via Krebs on Security »

Some financial institutions are now offering so-called “cardless ATM” transactions that allow customers to withdraw cash using nothing more than their mobile phones. But as the following story illustrates, this new technology also creates an avenue for thieves to quickly and quietly convert stolen customer bank account usernames and passwords into cold hard cash. Worse still, fraudulent cardless ATM withdrawals may prove more difficult for customers to dispute because they place the victim at the scene of the crime.

A portion of the third rejection letter that Markula received from Chase about her $2,900 fraud claim.
San Francisco resident Kristina Markula told KrebsOnSecurity that it wasn’t until shortly after a vacation in Cancun, Mexico in early November 2016 that she first learned that Chase Bank even offered cardless ATM access. Markula said that while she was still in Mexico she tried to view her bank balance using a Chase app on her smartphone, but that the app blocked her from accessing her account.

Markula said she thought at the time that Chase had blocked her from using the app because the request came from an unusual location. After all, she didn’t have an international calling or data plan and was trying to access the account via Wi-Fi at her hotel in Mexico.

Upon returning to the United States, Markula called the number on the back of her card and was told she needed to visit the nearest Chase bank branch and present two forms of identification. At a Chase branch in San Francisco, she handed the teller a California driver’s license and her passport. The branch manager told her that someone had used her Chase online banking username and password to add a new mobile phone number to her account, and then move $2,900 from her savings to her checking account.

The manager told Markula that whoever made the change then requested that a new mobile device be added to the account, and changed the contact email address for the account. Very soon after, that same new mobile device was used to withdraw $2,900 in cash from her checking account at the Chase Bank ATM in Pembroke Pines, Fla.

A handful of U.S. banks, including Chase, have deployed ATMs that are capable of dispensing cash without requiring an ATM card. In the case of Chase ATMs, the customer approaches the cash machine with a smart phone that is already associated with a Chase account. Associating an account with the mobile app merely requires the customer to supply the app with their online banking username and password.

Users then tell the Chase app how much they want to withdraw, and the app creates a unique 7-digit code that needs to be entered at the Chase ATM (instead of numeric code, some banks offering cardless ATM withdrawals will have the app display a QR code that needs to be read by a scanner on the ATM). Assuming the code checks out, the machine dispenses the requested cash and the transaction is complete. At no time is the Chase customer asked to enter his or her 4-digit ATM card PIN.

Most financial institutions will limit traditional ATM customers to withdrawing $300-$600 per transaction, but some banks have set cardless transaction limits at much higher amounts under certain circumstances. For example, at the time Markula’s fraud occurred, the limit was set at $3,000 for withdrawals during normal bank business hours and made at Chase ATMs located at Chase branches.

Markula said the bank employees helped her close the account and file a claim to dispute the withdrawal. She said the teller and the bank manager reviewed her passport and confirmed that the disputed transaction took place during the time between which her passport was stamped by U.S. and Mexican immigration authorities. However, Markula said Chase repeatedly denied her claims.

“We wanted to thank you for providing your information while we thoroughly researched your dispute,” Chase’s customer claims department wrote in the third rejection letter sent to Markula, dated January 5, 2017. “We confirmed that the disputed charges were correct and we will not be making an adjustment to your account.”

Markula said she was dumbfounded by the rejection letter because the last time she spoke with a fraud claims manager at Chase, the manager told her that the transaction had all of the hallmarks of an account takeover.

“I’m pretty frustrated at the process so far,” said Markula, who shared with this author a detailed timeline of events before and after the disputed transaction. “Not captured in this timeline are the countless phone calls to the fraud department which is routed overseas. The time it takes to reach someone and poor communication seems designed to make one want to give up.”

KrebsOnSecurity contacted Chase today about Markula’s case. Chase spokesman Mike Fusco said Markula’s rejection letter was incorrect, and that further investigation revealed she had been victimized by a group of a half-dozen fraudsters who were caught using the above-described technique to empty out Chase bank accounts.

Fusco forwarded this author a link to a Fox28 story about six men from Miami, Fla. who were arrested late last year in Columbus, Ohio in connection with what authorities there called a “multi-state crime spree” targeting Chase accounts.

“We escalated it and reviewed her issue and determined she did have fraud on her account,” Fusco said.  “We’re reimbursing her and we’re really sorry. This small pilot we ran allowed a limited number of customers to access cash at Chase ATMs without a card. During the pilot we detected some fraudulent activity where a group of people were able to go online and change the customer’s information and get the one-time access code, and we immediately notified the authorities.”

Chase declined to say how many like Markula were victimized by this gang. Unfortunately, somehow Chase neglected to notify victims, as Markula’s case shows.

“It makes you wonder how many other people didn’t dispute the charges,” she said. “Thankfully, I don’t give up easily.”

Fusco said Chase had made changes to better detect these types of fraudulent transactions going forward, and that it had lowered the withdrawal limit for these types of transactions — although for security reasons Fusco declined to say what the new limit was.

Fusco also said the bank’s system should have sent out an email alert to the original email on file in the event that the email on the account is changed, but Markula said she’s confident no such email ever landed in her inbox.

Avivah Litan, a fraud analyst at Gartner Inc., says many banks see mobile authentication as the way of the future for online banking and ATM transactions. She said most banks would love to be able to move away from physical bank cards, which often need to be replaced several times a year in response to data breaches at various retailers.

“A lot of banks see cardless transactions as a great way to reduce fraud and speed up transactions, but not many are offering it yet as a feature to customers,” Litan said.

Litan said Markula’s case echoes the spike in fraud that some banks saw after Apple debuted its Apple Pay platform. Many banks chose to adopt Apple Pay without also beefing up security around how they validate new customers and new mobile devices. As a result, this allowed fraudsters to take stolen credit card numbers and expiration dates — data that previously was only good for fraudulent online transactions — tie those cards to iPhones, and use the phones to commit card fraud at brick-and-mortar stores that accepted Apple Pay.

“Identity proofing remains the weakest point in mobile banking,” Litan said. “Asking for the customer’s username and password to on-board a new mobile device isn’t enough.”

Litan said Chase should require customers who wish to conduct cardless ATM transactions to enter their PIN in addition to the one-time code. But she said even that was not enough.

Litan said Chase should have flagged the transaction as highly suspicious from the get-go, given that the fraudsters accessed her account from a new location, changed her contact email address, added a new device and withdrew just under the daily maximum — all in a very short span of time.

“ATM transactions should have much stronger fraud controls because consumers don’t have as strong protections as they do with other transactions,” Litan said. “If a customer’s card is used fraudulently at a retailer, for example, the consumer is protected by Visa and MasterCard’s zero liability rule, and they can generally expect to get their money back. But when you withdraw cash from an ATM, you’re not protected by those rules. It’s down to Regulation E and your bank’s policies.”

Under the Federal Regulation E, if a retail banking customer reports fraud, the bank must investigate the first statement of the activity plus 60 days from the date the statement was mailed by the financial institution. Unless the institution can prove the transaction wasn’t fraud, it must reimburse the consumer. However, any activity that takes place outside of the aforementioned timeframe carries unlimited liability to the consumer, as the financial institution may have been able to prevent the loss had it been reported in a timely manner.

Fusco added that consumers should beware of phishing scams, and consider asking their financial institution to secure their accounts with a special passphrase or code that needs to be supplied when authenticating with the bank over the telephone (a precaution I have long advised).

Also, if your bank offers two-step or two-factor authentication — such as the requirement to send a text-message with a one-time code to your mobile device if someone attempts to log in from an unknown device or location — please take advantage of that feature. Twofactorauth.org has a list of banks that offer this additional security feature.

Also, as the Regulation E paragraph I hope makes clear, do not count on your bank to block fraudulent transfers, and remember that ultimately you are responsible for spotting and reporting fraudulent transactions.

Litan said she won’t be surprised if this incident gives more banks pause about moving to cardless ATM transactions.

“This is the first case I’m aware of in the United States where this type of fraud has been an issue,” she said. “I’m guessing this will slow the banks down a bit in adopting the technology because they’ll see now how easy it is for criminals to take advantage of it.”

Update, Jan. 6, 9:44 a.m. ET: Looks like Chase could have learned from the experience of NatWest, a big bank in the U.K. that experienced much the same fraud five years ago after enabling a cardless “get cash” feature.
Top

Debadging – Removing the model emblem from my 2017 Honda Civic

Postby Zach via The Z-Issue »

Last week I received an unexpected but great email that my new car had arrived way ahead of schedule. I had ordered a 2017 Honda Civic EX-T back in November, but it wasn’t slated to come in until February 2017. I had to order one from the factory because I wanted to get one that perfectly matched my needs and wants, and apparently, that’s rare. When the 2016 came out, I was uninspired because I wanted the 1.5L turbocharged engine instead of the 2.0L naturally aspirated one, and I also wanted some of the bells and whistles (like the larger display, more speakers, et cetera), but above all else, I wanted a manual transmission. For 2017, Honda came through in that I could get the manual transmission a trim higher than the base model. The EX-T had everything I wanted, and I picked it up on Friday, 30 December 2016.

As with all of my previous vehicles, there are things that I want to change about this car, but far fewer than ever before. I’m quite happy with the performance, the smooth ride, and the niceties that come with the higher trim level. Not even a week later, though, and I took on my first modification to the car (albeit a minor one). Though it wasn’t something as involved as swapping a JDM K20a / Y2M3 (from the ITR), it did make a noticeable difference with the car (just a cosmetic one this time).

Though I love the looks of the 2017 Civic, I think that the “Civic” emblem/badge makes the car look asymmetrical and a little less classy. So, I thought it best to remove it completely.

The process was relatively straightforward, but I understand that it can be a little unnerving to remove a badge on a brand new car. What happens if I scratch the paint? What if the adhesive is really strong and leaves a full residue? Those are legitimate concerns, but this little project turned out to be pretty easy. Here’s what I did:

  • Used a hair dryer to heat the adhesive behind each letter for ~60-90 seconds
  • Used a piece of floss in a seesaw motion behind each letter until they came off
  • Used an old credit card to remove some of the excess adhesive
  • Applied Goo Gone Automative Spray Gel to the remaining residue
  • Held a rag under the letters to catch the excess Goo Gone that would otherwise drip
  • Used my handy-dandy AmazonBasic microfiber cloth to get rid of the remaining residue
  • Washed the spot with some soap and water
  • Dried the spot with another microfiber cloth
  • Basked in the glory of having a much cleaner look to the rear of the car
I think that the results were well worth the minimal amount of time and effort:


Click each image to enlarge
The only thing that I would note is that I did need to apply a good amount of pressure when getting rid of the excessive adhesive with the old credit card, and especially when using the microfiber cloth & Goo Gone to clean the remaining residue. I was a bit nervous to press that hard at first, but soon realised that it was necessary, and as long as I was careful, it wouldn’t damage the clearcoat or the paint. I thought that it would take about 10 minutes, and it ended up taking about 45 to do it in my OCD manner. That being said, it could have been a lot worse. My friend Mike always used to say that “to estimate the time needed for a project—especially one involving a car—take your initial guess, multiply it by 2, and go up one unit of measure.” In that case, I’m glad that it didn’t take 20 hours.

Cheers,
Zach
Top

The Download on the DNC Hack

Postby BrianKrebs via Krebs on Security »

Over the past few days, several longtime readers have asked why I haven’t written about two stories that have consumed the news media of late: The alleged Russian hacking attacks against the U.S. Democratic National Committee (DNC) and, more recently, the discovery of malware on a laptop at a Vermont power utility that has been attributed to Russian hacker groups.

I’ve avoided covering these stories mainly because I don’t have any original reporting to add to them, and because I generally avoid chasing the story of the day — preferring instead to focus on producing original journalism on cybercrime and computer security.

But there is another reason for my reticence: Both of these stories are so politically fraught that to write about them means signing up for gobs of vitriolic hate mail from readers who assume I have some political axe to grind no matter what I publish on the matter.

An article in Rolling Stone over the weekend aptly captures my unease with reporting on both of these stories in the absence of new, useful information (the following quote refers specifically to the Obama administration’s sanctions against Russia related to the DNC incident).

“The problem with this story is that, like the Iraq-WMD mess, it takes place in the middle of a highly politicized environment during which the motives of all the relevant actors are suspect,” Rolling Stone political reporter Matt Taibbi wrote. “Absent independent verification, reporters will have to rely upon the secret assessments of intelligence agencies to cover the story at all. Many reporters I know are quietly freaking out about having to go through that again.”

Alas, one can only nurse a New Year’s holiday vacation for so long. Here are some of the things I’ve been ruminating about over the past few days regarding each of these topics. Please be kind.

Gaining sufficient public support for a conclusion that other countries are responsible for hacking important U.S. assets can be difficult – even when the alleged aggressor is already despised and denounced by the entire civilized world.

The remarkable hacking of Sony Pictures Entertainment in late 2014 and the Obama administration’s quick fingering of hackers in North Korea as the culprits is a prime example: When the Obama administration released its findings that North Korean hackers were responsible for breaking into SPE, few security experts I spoke to about the incident were convinced by the intelligence data coming from the White House.

That seemed to change somewhat following the leak of a National Security Agency document which suggested the United States had planted malware capable of tracking the inner workings of the computers and networks used by the North’s hackers. Nevertheless, I’d wager that if we took a scientific poll among computer security experts today, a fair percentage of them probably still strongly doubt the administration’s conclusions.

If you were to ask those doubting experts to explain why they persist in their unbelief, my guess is you would find these folks break down largely into two camps: Those who believe the administration will never release any really detailed (and likely classified) information needed to draw a more definitive conclusion, and those who because of their political leanings tend to disbelieve virtually everything that comes out of the current administration.

Now, the American public is being asked to accept the White House’s technical assessment of another international hacking incident, only this time the apparent intention of said hacking is nothing less than to influence the outcome of a historically divisive presidential election in which the sitting party lost.

It probably doesn’t matter how many indicators of compromise and digital fingerprints the Obama administration releases on this incident: Chances are decent that if you asked a panel of security experts a year from now whether the march of time and additional data points released or leaked in the interim have influenced their opinion, you’ll find them just as evenly divided as they are today.

The mixed messages coming from the camp of President-elect Trump haven’t added any clarity to the matter, either. Trump has publicly mocked American intelligence assessments that Russia meddled with the U.S. election on his behalf, and said recently that he doubts the U.S. government can be certain it was hackers backed by the Russian government who hacked and leaked emails from the DNC.

However, one of Trump’s top advisers — former CIA Director James Woolseynow says he believes the Russians (and possibly others) were in fact involved in the DNC hack.

It’s worth noting that the U.S. government has offered some additional perspective on why it is so confident in its conclusion that Russian military intelligence services were involved in the DNC hack. A White House fact sheet published alongside the FBI/DHS Joint Analysis Report (PDF) says the report “includes information on computers around the world that Russian intelligence services have co-opted without the knowledge of their owners in order conduct their malicious activity in a way that makes it difficult to trace back to Russia. In some cases, the cybersecurity community was aware of this infrastructure, in other cases, this information is newly declassified by the U.S. government.”

BREADCRUMBS

As I said in a tweet a few days back, the only remarkable thing about the hacking of the DNC is that the people responsible for protecting those systems somehow didn’t expect to be constantly targeted with email-based malware attacks. Lest anyone think perhaps the Republicans were better at anticipating such attacks, the FBI notified the Illinois Republican Party in June 2016 that some of its email accounts may have been hacked by the same group. The New York Times has reported that Russian hackers also broke into the DNC’s GOP counterpart — the Republican National Committee — but chose to release documents only on the Democrats.

I can’t say for certain if the Russian government was involved in directing or at least supporting attacks on U.S. political parties. But it seems to me they would be foolish not to have at least tried to get their least-hated candidate elected given how apparently easy it was to break in to the headquarters of both parties. Based on what I’ve learned over the past decade studying Russian language, culture and hacking communities, my sense is that if the Russians were responsible and wanted to hide that fact — they’d have left a trail leading back to some other country’s door.

That so many Russian hackers simply don’t bother to cover their tracks when attacking and plundering U.S. targets is a conclusion that many readers of this blog have challenged time and again, particularly with stories in my Breadcrumbs series. It’s too convenient and pat to be true, these detractors frequently claim. In my experience, however, if Russian hackers profiled on this blog were exposed because they did a poor job hiding their tracks, it’s usually because they didn’t even try.

In my view, this has more to do with the reality that there is very little chance these hackers will ever be held accountable for their crimes as long as they remain in Russia (or at least in former Soviet states that remain loyal to Russia). Take the case of Evgeniy Mikhailovich Bogachev, one of the hackers named in the U.S. government’s assessment of those responsible for the DNC attack.

Bogachev, the alleged Zeus Trojan author, in undated photos.
A Russian hacker better known by his hacker alias “Slavik” and as the author of the ZeuS Trojan malware, Bogachev landed on the FBI’s 10-most-wanted list in 2014. The cybercriminal organization Bogchev allegedly ran was responsible for the theft of more than $100 million from banks and businesses worldwide that were infected with his ZeuS malware. That organization, dubbed the “Business Club,” had members spanning most of Russia’s 11 time zones.

Fox-IT, a Dutch security firm that infiltrated the Business Club’s back-end operations, said that beginning in late fall 2013 — about the time that conflict between Ukraine and Russia was just beginning to heat up — Slavik retooled his cyberheist botnet to serve as purely a spying machine, and began scouring infected systems in Ukraine for specific keywords in emails and documents that would likely only be found in classified documents.

Likewise, the keyword searches that Slavik used to scour bot-infected systems in Turkey suggested the botmaster was searching for specific files from the Turkish Ministry of Foreign Affairs or the Turkish KOM – a specialized police unit. Fox-IT said it was clear that Slavik was looking to intercept communications about the conflict in Syria on Turkey’s southern border — one that Russia has supported by reportedly shipping arms into the region.

To date, Bogachev appears to be a free man, despite a $3 million bounty placed on his head by the FBI. This is likely because he’s remained inside Russia or at least within its sphere of protective influence. According to the FBI, Bogachev is known to enjoy boating and may be hiding out on a vessel somewhere in the Black Sea.

AN ‘INFRASTRUCTURE NEXUS’

For the relatively few Russian hackers who do wind up in Russian prisons as a result of their cybercriminal activity, agreeing to hack another government might be the easiest way to get out of jail. The New York Times carried a story last month about how how Russian hackers like Bogachev often get recruited or coerced by the Russian government to work on foreign intelligence-gathering operations.

The story noted that while “much about Russia’s cyberwarfare program is shrouded in secrecy, details of the government’s effort to recruit programmers in recent years — whether professionals like…college students, or even criminals — are shedding some light on the Kremlin’s plan to create elite teams of computer hackers.”

According to Times reporter Andrew Kramer, a convicted hacker named Dmitry A. Artimovich was approached by Russian intelligence services while awaiting trial for building malware that was used in crippling online attacks. Artimovich told Kramer that in prison while awaiting trial he was approached by a cellmate who told Artimovich he could get out of jail if he agreed to work for the government.

Artimovich said he declined the offer. He was convicted of hacking and later spent a year in a Russian penal colony for his crimes. Artimovich also was a central figure in my book, Spam Nation: The Inside Story of Organized Cybercrime, from Global Epidemic to Your Front Door. His exploits, and that of his brother Igor, are partially detailed in various posts on this blog, but the long and the short of them is that Artimovich created a botnet that was used mainly for spam.

That is, until a friend of his hired him to launch a cyberattack against a company that provided payment processing services to Aeroflot, an airline that is 51 percent owned by the Russian government.

For many years, Artimovich used his botnet, dubbed “Festi” by security researchers, to pump spam promoting male enhancement drugs for a rogue online pharmacy operations called Rx-PromotionPavel Vrublevsky, RX-Promotion’s founder and the man who hired Artimovich to launch the cyberattack — also was convicted in the same trial, and sentenced to two years in a penal colony. However, Vrublevsky was inexplicably released after less than a year in Russia’s hinterlands.

Vrublevsky’s company ChronoPay was indirectly featured in another New York Times story about the hacking of the DNC. In September, The Times profiled Vladimir M. Fomenko, the 26-year-old manager of the web hosting firm King Servers, which was “used by hackers in an incursion on computerized election systems in Arizona and Illinois.” U.S. cybersecurity firm ThreatConnect identified the infrastructure nexus between those attacks and cyberattacks on democratic processes in several countries, including Germany, Turkey and Ukraine.  [Full disclosure: ThreatConnect has been an advertiser on this blog.]

An image from ChronoPay’s press release.
To bring this full circle, on Sept. 15, 2016, Fomenko issued a statement about the ThreatConnect report. That statement, originally written in Russian, was translated from Russian into English by Vrublevsky, and reposted on ChronoPay’s Web site.

“The analysis of the internal data allows King Servers to confidently refute any conclusions about the involvement of the Russian special services in this attack,” Fomenko said in his statement, which credits ChronoPay for the translation. “The company also reported that the attackers still owe the company $US290 for rental services and King Servers send an invoice for the payment to Donald Trump & Vladimir Putin, as well as the company reserves the right to send it to any other person who will be accused by mass media of this attack.”

FOREIGN INTELLIGENCE BOTNETS

If indeed those who hacked the DNC were recruited from the ranks of the cybercriminal community focused mainly on financial crime, I would not be surprised in the least. The Russian source who first introduced me to much of the cyber underground told me exactly this when we first met some years ago. He had just left the Russian military for a job at a computer security firm in Russia, and his job was to build a presence on all of the Russian-language cybercrime forums and learn the real-life identities of the major power players in that space.

That source, who won’t be named here because it would compromise his current position and create legal problems for him, said he routinely saw Russian intelligence services recruiting hackers on cybercrime forums — particularly for research into potential vulnerabilities in the software and hardware that powers various national power grids and other energy infrastructure.

“All these guys had interest in hacking government resources, including Russian [targets],” my source told me. “Several years ago I got to know one of these hackers who worked for Russian government, [and] he operated his [cybercrime] forum as a government honeypot for hiring hackers. They were hiring hackers to work in official government organizations.”

Initially, he said, the hackers targeted U.S. military installations and U.S. news media outlets, but eventually they turned their attention to collecting government and corporate secrets full-time. The source said the teams routinely used botnets for foreign intelligence gathering and counterintelligence, and frequently sought to infiltrate botnets that were suspected of being co-opted for the same purposes by other countries.

“Then they started attacking foreign-only targets, and even started their own VPN (virtual private networking) service for English-speaking customers so they could capture corporate data,” he told me. “They also ran a service for checking stolen PDFs and other documents for [proprietary] data and classified information. If something like Stuxnet destroys some power plant, I will think about these guys first. Now I use them as a source of information about foreign intelligence botnets, so I really don’t want them to be uncovered.”

ARE WE NOT ENTERTAINED?

Perhaps it shouldn’t be surprising if many people remain unconvinced by the Joint Analysis Report released by the Obama administration. Fresh from an especially rancorous election muddled by the proliferation of “fake news” websites, public trust in the news media on technology and politics has to be at a historic low.

Last Friday, The Washington Post reported that Russian hackers penetrated the U.S. electricity grid through a utility in Vermont. The Post later significantly revised that story to clarify that malware tied to a Russian hacking group known to target companies in the energy sector had succeeded at infecting a single laptop at the utility, and that said laptop was never connected to the power grid.

To many already doubtful of the Obama administration’s claims about Russian hacking involvement in the election, The Post’s flub was yet another example of a left-leaning media establishment eager to capitalize on the Russian election-hacking narrative.

“From Russian hackers burrowed deep within the US electrical grid, ready to plunge the nation into darkness at the flip of a switch, an hour and a half later the story suddenly became that a single non-grid laptop had a piece of malware on it and that the laptop was not connected to the utility grid in any way,” wrote in Forbes.

Not that the American public is the best arbiter of truth and fiction. As Rolling Stone notes, despite the fact that election officials found virtually no voter fraud in the 2016 election, an Economist/YouGov poll conducted last month suggests that 50 percent of all Clinton voters believe the Russians hacked vote tallies. Not to be outdone, 62 percent of Trump voters said they believe Trump’s assertion that “millions” of undocumented immigrants likely voted in the election.

The public might also be deeply suspicious of hacking claims from a government that practically invented the art of meddling in foreign elections. As Nina Agrawal observes in The Los Angeles Times, the “U.S. has a long history of attempting to influence presidential elections in other countries – it’s done so as many as 81 times between 1946 and 2000, according to a database amassed by political scientist Dov Levin of Carnegie Mellon University.” Also, when it comes to hacking power plants, the U.S. and Israel have probably done more damage than anyone else with their incredibly complex Stuxnet virus, which was created as a weapon designed to delay Iran’s nuclear ambitions and opened a virtual Pandora’s Box.

In response to the alleged hacks, the Obama administration has expelled 35 Russian intelligence officials and imposed a series of economic sanctions on individuals and companies the administration says are connected to the DNC intrusions. The administration’s response has been criticized as lackluster and ineffectual, but it’s not entirely clear what else the White House could do publicly without risking retaliation in kind or worse.

However, the operative word there is “publicly.” Just as the administration almost certainly is not releasing all of the intelligence data that lead to its conclusion, I suspect that some of the U.S. response will materialize in ways that won’t be publicly acknowledged by this outgoing administration.
Top

This week in vc4 (2017-01-02): thread switching, CI

Postby Eric Anholt via anholt's lj »

The 3DMMES test has been thoroughly instruction count limited, so any wins we can get on code generation translate pretty directly into performance gains.  Last week I decided to work on fixing up Jonas's patch to schedule instructions in the delay slots of thread switching, which can save us 3 instructions per texture sample.

Thread switching, you may recall, is a trick in the fragment shader to hide texture fetch latency by cooperatively switching to another fragment shader instance after you request a texture fetch, so that it can make some progress when you'd probably be blocked anyway.  This lets us better occupy the ALUs, at the cost of each shader needing to fit into half of the physical register file.

However, VC4 doesn't cancel instructions in the pipeline when we request a switch (same as for within-shader branching), so 3 more instructions from the current shader get executed.  For my first implementation of thread switching, I just dumped in 3 NOPs after each THRSW to fill the delay slots.  This was still a massive win over not threading, so it was good enough.

Jonas's patch tries to fill the delay slots after we schedule in the thread switch by trying to extract the THRSW signal off of the instruction we scheduled and move it up to 2 instructions before that, and then only add enough NOPs to get us 3 slots filled.  There was a little bug (it re-scheduled the thrsw instruction instead of a NOP in trying to pad out to delay slots), but it basically worked and got us a 1.55% instruction count win on shader-db.

The problem was that he was scheduling ALU operations along with the thrsw, and if the thrsw signal was alone without an ALU operation in it, after moving the thrsw up we'd have a NOP left in the old location.  I wrote a followon patch to fix that: We now only schedule thrsws on their own without ALU operations, insert the THRSW as early as we can, and then add NOPs as necessary to fill remaining delay slots.  This was another 0.41% instruction count win.

This isn't as good as it could be.  Maybe we don't fill the slots as well as we could before choosing to schedule thrsw, but instructions we choose to schedule after that could be fit in.  Those would be tricky because we have to check that they don't write flags or the accumulators (which wouldn't be preserved across the thrsw) or new texture coordinates.  We also don't put the THRSW at any particular point in the timeline between sampler request and results collection.  We might be able to get wins by trying to put thrsw at the lowest-register-pressure point between them, so that fewer things need to be forced into physical regs instead of accumulators.

Those will be projects for later.  It's probably much more important that we figure out how to schedule 2-4 samples with a single thrsw, instead of doing a thrsw per sample like we do today.

The other project last week was starting to build up a plan for vc4 CI.  We've had a few regressions to vc4 in Mesa master because developers (including me!) don't do testing on vc4 hardware on every commit.  The Intel folks have a lovely CI system that does piglit, DEQP, and performance regression testing for them, both tracking Mesa master and doing pre-commit tests of voluntarily submitted branches.  I despaired of the work needed to build something that good, but apparently they've open sourced their configuration, so I'll be trying to replicate that in the next few weeks.  This week I worked on getting the hardware and a plan for where to host it.  I'm looking forward to a bright future of 30-minute test runs on the actual hardware and long-term tracking of performance metrics.  Unfortunately, there are no docs to it and I've never worked with jenkins before, so this is going to be a challenge.

Other things: I submitted a patch to mm/ to shut up the CMA warning we've been suffering from (and patching away downstream) for years, got exactly the expected response ("this dmesg spew in an common path might be useful for somebody debugging something some day, so it should stay there"), so hopefully we can just get Fedora and Debian to patch it out instead.  This is yet another data point in favor of Matthew Garrett's plan of "write kernel patches you need, don't bother submitting them upstream". Started testing a new patch to reduce error return rate on vc4 memory allocatoins on upstream kernel, haven't confirmed that it's working yet.  I also spent a lot of time reviewing tarceri's patches to Mesa preparing for the on-disk shader cache, which should help improve app startup times and reduce memory consumption.
Top

libtiff: NULL pointer dereference in TIFFReadRawData (tiffinfo.c)

Postby ago via agostino's blog »

Description:
Libtiff is a software that provides support for the Tag Image File Format (TIFF), a widely used format for storing image data.

A crafted tiff file revealed a NULL pointer access.

The complete ASan output:

# tiffinfo -Dijr $FILE

TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 384 (0x180) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 1093 (0x445) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 2 (0x2) encountered.
TIFFFetchNormalTag: Warning, ASCII value for tag "DocumentName" contains null byte in value; value incorrectly truncated during reading due to implementation limitations.
TIFFFetchNormalTag: Warning, Incorrect count for "JpegProc"; tag ignored.
TIFFReadDirectory: Warning, Photometric tag value assumed incorrect, assuming data is YCbCr instead of RGB.
TIFFReadDirectory: Warning, SamplesPerPixel tag is missing, applying correct SamplesPerPixel value of 3.
_TIFFVSetField: Warning, SamplesPerPixel tag value is changing, but SMinSampleValue tag was read with a different value. Cancelling it.
ASAN:DEADLYSIGNAL
=================================================================
==15897==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000050d8ad bp 0x7ffc4a3eaf90 sp 0x7ffc4a3eaec0 T0)
==15897==The signal is caused by a READ memory access.
==15897==Hint: address points to the zero page.
    #0 0x50d8ac in TIFFReadRawData /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffinfo.c:421:29
    #1 0x50b2de in tiffinfo /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffinfo.c:473:4
    #2 0x50a999 in main /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffinfo.c:152:6
    #3 0x7f6258f0961f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #4 0x419f38 in _init (/usr/bin/tiffinfo+0x419f38)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffinfo.c:421:29 in TIFFReadRawData
==15897==ABORTING
TIFF Directory at offset 0xc (12)
  Image Width: 128 Image Length: 1
  Bits/Sample: 32189
  Compression Scheme: Old-style JPEG
  Photometric Interpretation: YCbCr
  YCbCr Subsampling: 2, 2
  Samples/Pixel: 3
  Rows/Strip: 2048
  Planar Configuration: single image plane
  DocumentName: 
  Tag 384: 16779264
Affected version:
4.0.7

Fixed version:
N/A

Commit fix:
https://github.com/vadz/libtiff/commit/c2f931bb558b9db41cb3516a6df3aa600fd85744

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00056-libtiff-nullptr-TIFFReadRawData

Timeline:
2016-11-22: bug discovered and reported to upstream
2016-12-03: upstream released a patch
2017-01-01: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libtiff: NULL pointer dereference in TIFFReadRawData (tiffinfo.c)

Top

libtiff: assertion failure in readSeparateTilesIntoBuffer (tiffcp.c)

Postby ago via agostino's blog »

Description:
Libtiff is a software that provides support for the Tag Image File Format (TIFF), a widely used format for storing image data.

A crafted tiff file revealed an assertion failure.

The complete output:

# tiffcp -i $FILE /tmp/foo
tiffcp: /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffcp.c:1390:
int readSeparateTilesIntoBuffer(TIFF *, uint8 *, uint32, uint32, tsample_t):
Assertion `bps % 8 == 0' failed.
Affected version:
4.0.7

Fixed version:
N/A

Commit fix:
https://github.com/vadz/libtiff/commit/7ff9652da2eec4c65279dcbc7e55c0418e87bbc8

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00072-libtiff-assert-readSeparateTilesIntoBuffer

Timeline:
2016-11-23: bug discovered and reported to upstream
2016-12-03: upstream released a patch
2017-01-01: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libtiff: assertion failure in readSeparateTilesIntoBuffer (tiffcp.c)

Top

libtiff: stack-based buffer overflow in _TIFFVGetField (tif_dir.c)

Postby ago via agostino's blog »

Description:
Libtiff is a software that provides support for the Tag Image File Format (TIFF), a widely used format for storing image data.

A crafted tiff file revealed a stack buffer overflow.

The complete ASan output:

# tiffsplit $FILE
TIFFReadDirectory: Warning, Unknown field with tag 317 (0x13d) encountered.
=================================================================
==10362==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f3824f00090 at pc 0x7f3829624fbb bp 0x7fffe0eb1da0 sp 0x7fffe0eb1d98
WRITE of size 4 at 0x7f3824f00090 thread T0
    #0 0x7f3829624fba in _TIFFVGetField /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_dir.c:1077:29
    #1 0x7f382960f202 in TIFFVGetField /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_dir.c:1198:6
    #2 0x7f382960f202 in TIFFGetField /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_dir.c:1182
    #3 0x50a719 in tiffcp /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffsplit.c:183:2
    #4 0x50a719 in main /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffsplit.c:89
    #5 0x7f382871561f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #6 0x419a78 in _init (/usr/bin/tiffsplit+0x419a78)

Address 0x7f3824f00090 is located in stack of thread T0 at offset 144 in frame
    #0 0x5099cf in main /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffsplit.c:59

  This frame has 18 object(s):
    [32, 40) 'bytecounts.i263.i'
    [64, 72) 'bytecounts.i.i'
    [96, 98) 'bitspersample.i'
    [112, 114) 'samplesperpixel.i'
    [128, 130) 'compression.i'
    [144, 146) 'shortv.i' 0x0fe7849d8010: 02 f2[02]f2 00 f2 f2 f2 04 f2 04 f2 04 f2 00 f2
  0x0fe7849d8020: f2 f2 04 f2 04 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2
  0x0fe7849d8030: f2 f2 00 f2 f2 f2 02 f3 00 00 00 00 00 00 00 00
  0x0fe7849d8040: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x0fe7849d8050: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x0fe7849d8060: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==10362==ABORTING
Affected version:
4.0.7

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-10095

Reproducer:
https://github.com/asarubbo/poc/blob/master/00104-libtiff-stackoverflow-_TIFFVGetField

Timeline:
2016-12-04: bug discovered and reported to upstream
2017-01-01: blog post about the issue
2017-01-01: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libtiff: stack-based buffer overflow in _TIFFVGetField (tif_dir.c)

Top

libtiff: memcpy-param-overlap in t2p_tile_collapse_left (tiff2pdf.c)

Postby ago via agostino's blog »

Description:
Libtiff is a software that provides support for the Tag Image File Format (TIFF), a widely used format for storing image data.

A crafted tiff file revealed a memcpy-param-overlap.

The complete ASan output:

# tiff2pdf $FILE -o foo
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 2 (0x2) encountered.
1006.crashes: Warning, Nonstandard tile width 769, convert file.
TIFFReadDirectory: Warning, Unknown field with tag 7710 (0x1e1e) encountered.
TIFFFetchNormalTag: Warning, Incorrect count for "FillOrder"; tag ignored.
TIFFFetchNormalTag: Warning, Incorrect count for "XResolution"; tag ignored.
TIFFAdvanceDirectory: Error fetching directory count.
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 2 (0x2) encountered.
1006.crashes: Warning, Nonstandard tile width 769, convert file.
TIFFReadDirectory: Warning, Unknown field with tag 7710 (0x1e1e) encountered.
TIFFFetchNormalTag: Warning, Incorrect count for "FillOrder"; tag ignored.
TIFFFetchNormalTag: Warning, Incorrect count for "XResolution"; tag ignored.
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 2 (0x2) encountered.
1006.crashes: Warning, Nonstandard tile width 769, convert file.
TIFFReadDirectory: Warning, Unknown field with tag 7710 (0x1e1e) encountered.
TIFFFetchNormalTag: Warning, Incorrect count for "FillOrder"; tag ignored.
TIFFFetchNormalTag: Warning, Incorrect count for "XResolution"; tag ignored.
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 2 (0x2) encountered.
1006.crashes: Warning, Nonstandard tile width 769, convert file.
TIFFReadDirectory: Warning, Unknown field with tag 7710 (0x1e1e) encountered.
TIFFFetchNormalTag: Warning, Incorrect count for "FillOrder"; tag ignored.
TIFFFetchNormalTag: Warning, Incorrect count for "XResolution"; tag ignored.
Fax3Decode2D: Warning, Premature EOL at line 0 of tile 0 (got 768, expected 769).
Fax3Decode2D: Warning, Premature EOL at line 1 of tile 0 (got 35, expected 769).
Fax3Decode2D: Warning, Premature EOL at line 2 of tile 0 (got 0, expected 769).
Fax3Decode2D: Warning, Premature EOL at line 3 of tile 0 (got 0, expected 769).
Fax3Decode2D: Uncompressed data (not supported) at line 4 of tile 0 (x 0).
Fax3Decode2D: Warning, Premature EOL at line 4 of tile 0 (got 0, expected 769).
Fax3Decode2D: Warning, Premature EOL at line 5 of tile 0 (got 0, expected 769).
Fax3Decode2D: Warning, Premature EOL at line 7 of tile 0 (got 0, expected 769).
Fax3Decode2D: Warning, Premature EOL at line 8 of tile 0 (got 0, expected 769).
Fax3Decode2D: Warning, Premature EOL at line 9 of tile 0 (got 0, expected 769).
Fax3Decode2D: Warning, Line length mismatch at line 10 of tile 0 (got 1792, expected 769).
Fax3Decode2D: Warning, Premature EOL at line 11 of tile 0 (got 0, expected 769).
=================================================================
==29687==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x7f2dcce0b85d,0x7f2dcce0b8ba) and [0x7f2dcce0b861, 0x7f2dcce0b8be) overlap
    #0 0x4bbee1 in __asan_memcpy /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:413
    #1 0x7f2dccb87f0d in _TIFFmemcpy /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_unix.c:340:2
    #2 0x52ac36 in t2p_tile_collapse_left /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:3596:3
    #3 0x52ac36 in t2p_readwrite_pdf_image_tile /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:3073
    #4 0x50f1dc in t2p_write_pdf /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:5526:16
    #5 0x50bfee in main /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:808:2
    #6 0x7f2dcbb4361f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #7 0x41a298 in _init (/usr/bin/tiff2pdf+0x41a298)

0x7f2dcce0b85d is located 93 bytes inside of 968448-byte region [0x7f2dcce0b800,0x7f2dccef7f00)
allocated by thread T0 here:
    #0 0x4d3058 in malloc /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
    #1 0x7f2dccb87d7e in _TIFFmalloc /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_unix.c:316:10
    #2 0x5294e8 in t2p_readwrite_pdf_image_tile /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:2933:29
    #3 0x50f1dc in t2p_write_pdf /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:5526:16
    #4 0x50bfee in main /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:808:2
    #5 0x7f2dcbb4361f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289

0x7f2dcce0b861 is located 97 bytes inside of 968448-byte region [0x7f2dcce0b800,0x7f2dccef7f00)
allocated by thread T0 here:
    #0 0x4d3058 in malloc /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
    #1 0x7f2dccb87d7e in _TIFFmalloc /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_unix.c:316:10
    #2 0x5294e8 in t2p_readwrite_pdf_image_tile /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:2933:29
    #3 0x50f1dc in t2p_write_pdf /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:5526:16
    #4 0x50bfee in main /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:808:2
    #5 0x7f2dcbb4361f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289

SUMMARY: AddressSanitizer: memcpy-param-overlap /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:413 in __asan_memcpy
==29687==ABORTING
Affected version:
4.0.7

Fixed version:
N/A

Commit fix:
https://github.com/vadz/libtiff/commit/ad2fccbf5c23da10c5859114a6018a37fdd05095

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00110-libtiff-memcpy-param-overlap-_TIFFmemcpy

Timeline:
2016-12-20: bug discovered and reported to upstream
2016-12-20: upstream released a patch
2017-01-01: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libtiff: memcpy-param-overlap in t2p_tile_collapse_left (tiff2pdf.c)

Top

libtiff: invalid memory READ in t2p_writeproc (tiff2pdf.c)

Postby ago via agostino's blog »

Description:
Libtiff is a software that provides support for the Tag Image File Format (TIFF), a widely used format for storing image data.

A crafted tiff file revealed an invalid memory read.

The complete ASan output:

# tiff2pdf $FILE -o foo
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
111.crashes: Warning, Nonstandard tile length 3, convert file.
TIFFFetchNormalTag: Warning, Incorrect count for "XResolution"; tag ignored.
TIFFFetchNormalTag: Warning, ASCII value for tag "Software" contains null byte in value; value incorrectly truncated during reading due to implementation limitations.
TIFFAdvanceDirectory: Error fetching directory count.
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
111.crashes: Warning, Nonstandard tile length 3, convert file.
TIFFFetchNormalTag: Warning, Incorrect count for "XResolution"; tag ignored.
TIFFFetchNormalTag: Warning, ASCII value for tag "Software" contains null byte in value; value incorrectly truncated during reading due to implementation limitations.
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
111.crashes: Warning, Nonstandard tile length 3, convert file.
TIFFFetchNormalTag: Warning, Incorrect count for "XResolution"; tag ignored.
TIFFFetchNormalTag: Warning, ASCII value for tag "Software" contains null byte in value; value incorrectly truncated during reading due to implementation limitations.
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
111.crashes: Warning, Nonstandard tile length 3, convert file.
TIFFFetchNormalTag: Warning, Incorrect count for "XResolution"; tag ignored.
TIFFFetchNormalTag: Warning, ASCII value for tag "Software" contains null byte in value; value incorrectly truncated during reading due to implementation limitations.
tiff2pdf: Warning, RGB image 111.crashes has 4 samples per pixel, assuming RGBA.
TIFFReadRawTile: Read error at row 4294967295, col 4294967295, tile 0; got 0 bytes, expected 23297.
TIFFReadRawTile: Read error at row 4294967295, col 4294967295, tile 1; got 0 bytes, expected 513.
TIFFReadRawTile: Read error at row 4294967295, col 4294967295, tile 2; got 512 bytes, expected 65285.
TIFFReadRawTile: Read error at row 4294967295, col 4294967295, tile 3; got 512 bytes, expected 1535.
ASAN:DEADLYSIGNAL
=================================================================
==19864==ERROR: AddressSanitizer: SEGV on unknown address 0x61b000020000 (pc 0x7fc86d4a320b bp 0x000000000efc sp 0x7fff06650bf8 T0)
==19864==The signal is caused by a READ memory access.
    #0 0x7fc86d4a320a  /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/string/../sysdeps/x86_64/memcpy.S:270
    #1 0x7fc86d491f79 in _IO_file_xsputn /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/libio/fileops.c:1319
    #2 0x7fc86d487828 in fwrite /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/libio/iofwrite.c:43
    #3 0x50cdff in t2p_writeproc /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:405:21
    #4 0x52baea in t2pWriteFile /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:379:10
    #5 0x52baea in t2p_readwrite_pdf_image_tile /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:2924
    #6 0x50f1dc in t2p_write_pdf /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:5526:16
    #7 0x50bfee in main /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2pdf.c:808:2
    #8 0x7fc86d43e61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #9 0x41a298 in _init (/usr/bin/tiff2pdf+0x41a298)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/string/../sysdeps/x86_64/memcpy.S:270 
==19864==ABORTING
Affected version:
4.0.7

Fixed version:
N/A

Commit fix:
https://github.com/vadz/libtiff/commit/891b1b908eb92a0e91e9012a8d32ade7088b5a3f

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00111-libtiff-invalidread-t2p_writeproc

Timeline:
2016-12-20: bug discovered and reported to upstream
2016-12-20: upstream released a patch
2017-01-01: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libtiff: invalid memory READ in t2p_writeproc (tiff2pdf.c)

Top

libtiff: multiple heap-based buffer overflow

Postby ago via agostino's blog »

Description:
Libtiff is a software that provides support for the Tag Image File Format (TIFF), a widely used format for storing image data.

Some crafted images, through a fuzzing revealed multiple overflow. Since the number of the issues, I will post the relevant part of the stacktrace.

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/5397a417e61258c69209904e652a1f409ec3b9df
Reproducer:
https://github.com/asarubbo/poc/blob/master/00068-libtiff-heapoverflow-_tiffWriteProc
Relevant part of the stacktrace:

# tiffcp -i $FILE /tmp/foo
==16440==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62500000e861 at pc 0x0000004531de bp 0x7ffd2aba5c30 sp 0x7ffd2aba53e0
READ of size 78490 at 0x62500000e861 thread T0
    #1 0x7f280456d37b in _tiffWriteProc /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_unix.c:115:23
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/5397a417e61258c69209904e652a1f409ec3b9df
Reproducer:
https://github.com/asarubbo/poc/blob/master/00066-libtiff-heapoverflow-TIFFReverseBits
Relevant part of the stacktrace:

# tiffcp -i $FILE /tmp/foo
==14332==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x63000000f4f0 at pc 0x7f95e90c11ad bp 0x7ffd74ba5ca0 sp 0x7ffd74ba5c98
READ of size 1 at 0x63000000f4f0 thread T0
    #0 0x7f95e90c11ac in TIFFReverseBits /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_swab.c:289:27
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/1044b43637fa7f70fb19b93593777b78bd20da86
Reproducer:
https://github.com/asarubbo/poc/blob/master/00071-libtiff-heapoverflow-_TIFFmemcpy
Relevant part of the stacktrace:

#tiffcp -i $FILE /tmp/foo
==10398==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eef4 at pc 0x0000004bc235 bp 0x7fff3ebfa700 sp 0x7fff3ebf9eb0
READ of size 512 at 0x60200000eef4 thread T0
     #1 0x7fcaf590cf0d in _TIFFmemcpy /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_unix.c:340:2
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/9a72a69e035ee70ff5c41541c8c61cd97990d018
Reproducer:
https://github.com/asarubbo/poc/blob/master/00074-libtiff-heapoverflow-TIFFFillStrip
Relevant part of the stacktrace:

# tiffcp -i $FILE /tmp/foo
==15106==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000edd8 at pc 0x7f33918c5de3 bp 0x7ffc5abe6ba0 sp 0x7ffc5abe6b98
READ of size 8 at 0x60200000edd8 thread T0
    #0 0x7f33918c5de2 in TIFFFillStrip /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_read.c:523:22
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/9657bbe3cdce4aaa90e07d50c1c70ae52da0ba6a
Reproducer:
https://github.com/asarubbo/poc/blob/master/00100-libtiff-heapoverflow-_TIFFFax3fillruns
Relevant part of the stacktrace:

# tiffcrop -i $FILE /tmp/foo
==9181==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd3b2e277f8 at pc 0x7fd3b7a762cc bp 0x7ffffd6e2550 sp 0x7ffffd6e2548
READ of size 1 at 0x7fd3b2e277f8 thread T0
    #0 0x7fd3b7a762cb in _TIFFFax3fillruns /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_fax3.c:413:13
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/9657bbe3cdce4aaa90e07d50c1c70ae52da0ba6a
Reproducer:
https://github.com/asarubbo/poc/blob/master/00102-libtiff-heapoverflow-_TIFFmemcpy
Relevant part of the stacktrace:

# tiffcrop -i $FILE /tmp/foo
==988==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62100001ccff at pc 0x0000004bc00c bp 0x7fff920da690 sp 0x7fff920d9e40
WRITE of size 1 at 0x62100001ccff thread T0
    #1 0x7f49edd6af0d in _TIFFmemcpy /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_unix.c:340:2
CVE:
CVE-2016-10092

###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/b4b41925115059b49f97432bda0613411df2f686
Reproducer:
https://github.com/asarubbo/poc/blob/master/00067-libtiff-heapoverflow-tiffcp
Relevant part of the stacktrace:

# tiffcp -i $FILE /tmp/foo
==7788==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000edd3 at pc 0x0000004629ac bp 0x7ffe4adf8df0 sp 0x7ffe4adf85a0
READ of size 1 at 0x60200000edd3 thread T0
    #1 0x50d6a5 in tiffcp /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffcp.c:784:57
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
Upstream said that the previous changes, fixes this too. It needs to be bisected.
Reproducer:
https://github.com/asarubbo/poc/blob/master/00079-libtiff-heapoverflow-cpSeparateBufToContigBuf
Relevant part of the stacktrace:

# tiffcp -i $FILE /tmp/foo
==25645==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f651cc3b800 at pc 0x00000051ef24 bp 0x7ffec0573a70 sp 0x7ffec0573a68
READ of size 16 at 0x7f651cc3b800 thread T0
    #0 0x51ef23 in cpSeparateBufToContigBuf /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffcp.c:1209:14
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/787c0ee906430b772f33ca50b97b8b5ca070faec
Reproducer:
https://github.com/asarubbo/poc/blob/master/00082-libtiff-heap-overflow-cpStripToTile
Relevant part of the stacktrace:

# tiffcp -i $FILE /tmp/foo
==20438==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fef2adde803 at pc 0x00000051befa bp 0x7ffd3ee26b50 sp 0x7ffd3ee26b48
WRITE of size 16 at 0x7fef2adde803 thread T0
    #0 0x51bef9 in cpStripToTile /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffcp.c:1171:11
CVE:
CVE-2016-10093

###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
Upstream said that the previous changes, fixes this too. It needs to be bisected.
Reproducer:
https://github.com/asarubbo/poc/blob/master/00103-libtiff-heapoverflow-NeXTDecode
Relevant part of the stacktrace:

# tiffcrop -i $FILE /tmp/foo
==29649==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62d00000a3fc at pc 0x0000004bc48c bp 0x7ffd6f23c680 sp 0x7ffd6f23be30
WRITE of size 2048 at 0x62d00000a3fc thread T0
      #1 0x7fcac5ac0033 in NeXTDecode /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_next.c:64:9
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
Upstream said that the previous changes, fixes this too. It needs to be bisected.
Reproducer:
https://github.com/asarubbo/poc/blob/master/00102-libtiff-heapoverflow-_TIFFmemcpy
Relevant part of the stacktrace:

# tiffcrop -i $FILE /tmp/foo
==23091==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eed2 at pc 0x0000004629dc bp 0x7fff8d1e2950 sp 0x7fff8d1e2100
READ of size 1 at 0x60200000eed2 thread T0
   #1 0x53277f in writeCroppedImage /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffcrop.c:7940:23
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/5ed9fea523316c2f5cec4d393e4d5d671c2dbc33
Reproducer:
https://github.com/asarubbo/poc/blob/master/00108-libtiff-heapoverflow-PSDataBW
Relevant part of the stacktrace:

# tiff2ps $FILE
==32416==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000ee91 at pc 0x00000051ea78 bp 0x7ffd76b73dd0 sp 0x7ffd76b73dc8
READ of size 1 at 0x60200000ee91 thread T0
    #0 0x51ea77 in PSDataBW /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2ps.c:2703:21
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/5ed9fea523316c2f5cec4d393e4d5d671c2dbc33
Reproducer:
https://github.com/asarubbo/poc/blob/master/00107-libtiff-heapoverflow-PSDataColorContig
Relevant part of the stacktrace:

# tiff2ps $FILE
==31384==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000ee54 at pc 0x000000518b75 bp 0x7fff437bfdb0 sp 0x7fff437bfda8
READ of size 1 at 0x60200000ee54 thread T0
    #0 0x518b74 in PSDataColorContig /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiff2ps.c:2470:2
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/bd9d7670d0224412b3bd146e221658211ece876e
Reproducer:
https://github.com/asarubbo/poc/blob/master/00101-libtiff-heapoverflow-combineSeparateSamples16bits
Relevant part of the stacktrace:

# tiffcrop -i $FILE /tmp/foo
==8016==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eef1 at pc 0x000000530805 bp 0x7ffeb0d41770 sp 0x7ffeb0d41768
READ of size 1 at 0x60200000eef1 thread T0
    #0 0x530804 in combineSeparateSamples16bits /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffcrop.c:3913:20
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/c7153361a4041260719b340f73f2f76b0969235c
Reproducer:
https://github.com/asarubbo/poc/blob/master/00112-libtiff-heapoverflow-_TIFFmemcpy
Relevant part of the stacktrace:

# tiff2pdf $FILE -o foo
==31315==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000ea11 at pc 0x0000004bc10c bp 0x7fffd59abc40 sp 0x7fffd59ab3f0
WRITE of size 2 at 0x60200000ea11 thread T0
    #1 0x7fd49c1adf0d in _TIFFmemcpy /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_unix.c:340:2
CVE:
CVE-2016-10094

###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
N/A
Reproducer:
https://github.com/asarubbo/poc/blob/master/00109-libtiff-heapoverflow-putcontig8bitYCbCr44tile
Relevant part of the stacktrace:

# tiff2rgba $FILE /tmp/foo
==20699==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62500000ed12 at pc 0x7f49ab2c134c bp 0x7ffc7e4eda30 sp 0x7ffc7e4eda28                                                                                                                                      
READ of size 1 at 0x62500000ed12 thread T0                                                                                                                                                                                                                                     
    #0 0x7f49ab2c134b in putcontig8bitYCbCr44tile /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_getimage.c:1885:28
Credit:
These bugs were discovered by Agostino Sarubbo of Gentoo.

Timeline:
2016-11-20: started to post the issues to upstream
2017-01-01: blog post about the issue
2017-01-01: CVE assigned

Note:
These bugs were found with American Fuzzy Lop.

Permalink:

libtiff: multiple heap-based buffer overflow

Top

libtiff: multiple divide-by-zero

Postby ago via agostino's blog »

Description:
Libtiff is a software that provides support for the Tag Image File Format (TIFF), a widely used format for storing image data.

Some crafted images, through a fuzzing revealed multiple division by zero. Since the number of the issues, I will post the relevant part of the stacktrace.

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/438274f938e046d33cb0e1230b41da32ffe223e1
Reproducer:
https://github.com/asarubbo/poc/blob/master/00064-libtiff-fpe-TIFFReadEncodedStrip
Relevant part of the stacktrace:

# tiffcp $FILE /tmp/foo
==12079==ERROR: AddressSanitizer: FPE on unknown address 0x7fd319436251 (pc 0x7fd319436251 bp 0x7fff851e3d80 sp 0x7fff851e3d30 T0)
    #0 0x7fd319436250 in TIFFReadEncodedStrip /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_read.c:351:22
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/43bc256d8ae44b92d2734a3c5bc73957a4d7c1ec
Reproducer:
https://github.com/asarubbo/poc/blob/master/00083-libtiff-fpe-OJPEGDecodeRaw
Relevant part of the stacktrace:

# tiffmedia $FILE /tmp/foo
==28106==ERROR: AddressSanitizer: FPE on unknown address 0x7faeae7f744e (pc 0x7faeae7f744e bp 0x7ffceab45e40 sp 0x7ffceab45ce0 T0)
    #0 0x7faeae7f744d in OJPEGDecodeRaw /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/libtiff/tif_ojpeg.c:816:8
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/d3c5426395dc53e3345712ac7246c29db9fed8fa
Reproducer:
https://github.com/asarubbo/poc/blob/master/00099-libtiff-fpe-readSeparateStripsIntoBuffer
Relevant part of the stacktrace:

# tiffcrop $FILE /tmp/foo
==19098==ERROR: AddressSanitizer: FPE on unknown address 0x000000523acf (pc 0x000000523acf bp 0x7ffcb22ada30 sp 0x7ffcb22ad780 T0)
    #0 0x523ace in readSeparateStripsIntoBuffer /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffcrop.c:4841:36
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/a87eb62049f446204ed62c939f965eb76bd98001
Reproducer:
https://github.com/asarubbo/poc/blob/master/00065-libtiff-fpe-readSeparateTilesIntoBuffer
Relevant part of the stacktrace:

# tiffcp $FILE /tmp/foo
==13262==ERROR: AddressSanitizer: FPE on unknown address 0x00000051c43b (pc 0x00000051c43b bp 0x7ffdc8d81d70 sp 0x7ffdc8d81b20 T0)
    #0 0x51c43a in readSeparateTilesIntoBuffer /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffcp.c:1434:9
###############################################

Affected version / Tested on:
4.0.7
Fixed version:
N/A
Commit fix:
https://github.com/vadz/libtiff/commit/296803e79542f5523be1009d64574507b9acc239
Reproducer:
https://github.com/asarubbo/poc/blob/master/00073-libtiff-fpe-writeBufferToSeparateTiles
Relevant part of the stacktrace:

# tiffcp -i $FILE /tmp/foo
==3614==ERROR: AddressSanitizer: FPE on unknown address 0x00000051650a (pc 0x00000051650a bp 0x7fff41587d30 sp 0x7fff41587b00 T0)
    #0 0x516509 in writeBufferToSeparateTiles /tmp/portage/media-libs/tiff-4.0.7/work/tiff-4.0.7/tools/tiffcp.c:1591:13
Credit:
These bugs were discovered by Agostino Sarubbo of Gentoo.

Timeline:
2016-11-20: started to post the issues to upstream
2017-01-01: blog post about the issue

Note:
These bugs were found with American Fuzzy Lop.

Permalink:

libtiff: multiple divide-by-zero

Top

Happy Seventh Birthday, KrebsOnSecurity!

Postby BrianKrebs via Krebs on Security »

Hard to believe it’s time to celebrate another go ’round the Sun for KrebsOnSecurity! Today marks exactly seven years since I left The Washington Post and started this here solo thing. And what a remarkable year 2016 has been!



The word cloud above includes a sampling of tags used in stories on KrebsOnSecurity throughout the past year. It’s been a wild one, riddled with huge attacks, big cybercriminal busts and of course a whole mess of data breaches.

The biggest attack of all — the 620 Gbps distributed denial-of-service (DDoS) assault against this site on Sept. 22 — resulted in KrebsOnSecurity being unplugged for several days. The silver lining? I now have a stronger site and readership. Through it all, the community that has grown up around this site was extremely supportive and encouraging. I couldn’t be prouder of this community, so a huge THANK YOU to all of my readers, both new and old.

It’s fair to say that many of the subjects in the word cloud above are going to continue to haunt us in 2017, particularly ransomware, CEO fraud and DDoS attacks. I am hopeful to have more on the “who” behind the September attacks against this site in the New Year. I promise it’s going to be a story worth waiting for. Stay tuned.

Also, many of you have asked whether we can have a more responsive theme on this blog. It is true that the site hasn’t been updated appearance-wise since it launched seven years ago, and that it’s long overdue for a facelift. We were on track to have that done by today’s blog post, but for a variety of reasons this will have to wait until the early New Year. Thank you for your patience.

My aim from the beginning with this site has been to focus on producing original, impactful reporting on computer security and cybercrime, and to keep the content free for anyone and everyone. That remains my intention. For those of you who have Adblock installed, please consider adding an exception for my site: For security reasons (see malvertising for more info), this site has not allowed third-party content since late 2011, and all of the handful of ads that run here are hosted locally and have been fully vetted.

As always, below are links to some of the most-read stories on the site this year. Thanks again for your readership, encouragement and support!

Oct. 21: Hacked Cameras, DVRs Powered Today’s Massive Internet Outage

Oct. 3: Who Makes the IoT Things Under Attack?

Sept. 25: The Democratization of Censorship

Sept. 13: Secret Service Warns of ‘Periscope’ Skimmers

Sept. 10: Alleged vDOS Proprietors Arrested in Israel

Sept. 8: Israeli Online Attack Service ‘vDOS’ Earned $600,000 in Two Years

Aug. 26: Inside ‘The Attack that Almost Broke the Internet’

Feb. 18: This is Why People Fear the Internet of Things

Feb. 16: The Great EMV Fakeout: No Chip for You!

Jan. 30: Sources: Security Firm Norse Corp. Imploding
Top

Holiday Inn Parent IHG Probes Breach Claims

Postby BrianKrebs via Krebs on Security »

InterContinental Hotels Group (IHG), the parent company for more than 5,000 hotels worldwide including Holiday Inn, says it is investigating claims of a possible credit card breach at some U.S. locations.

An Intercontinental hotel in New York City. Photo: IHG.
Last week, KrebsOnSecurity began hearing from sources who work in fraud prevention at different financial institutions. Those sources said they were seeing a pattern of fraud on customer credit and debit cards that suggested a breach at some IHG properties — particularly Holiday Inn and Holiday Inn Express locations.

Asked about the fraud patterns reported by my sources, a spokesperson for IHG said the company had received similar reports, and that it has hired an outside security firm to help investigate. IHG also issued the following statement:

“IHG takes the protection of payment card data very seriously. We were made aware of a report of unauthorized charges occurring on some payment cards that were recently used at a small number of U.S.-based hotel locations.  We immediately launched an investigation, which includes retaining a leading computer security firm to provide us with additional support.  We continue to work with the payment card networks.”

“We are committed to swiftly resolving this matter. In the meantime, and in line with best practice, we recommend that individuals closely monitor their payment card account statements.  If there are unauthorized charges, individuals should immediately notify their bank. Payment card network rules generally state that cardholders are not responsible for such charges.”

Headquartered in Denham, U.K., IHG operates more than 5,000 hotels across nearly 100 countries. The company’s dozen brands include Holiday Inn, Holiday Inn Express, InterContinental, Kimpton Hotels, and Crowne Plaza.

Card-stealing cyber thieves have broken into some of the largest hotel chains over the past few years. Hotel brands that have acknowledged card breaches over the last year after prompting by KrebsOnSecurity include Kimpton HotelsTrump Hotels (twice), Hilton, Mandarin Oriental, and White Lodging (twice). Card breaches also have hit hospitality chains Starwood Hotels and Hyatt.

In many of those incidents, thieves planted malicious software on the point-of-sale devices at restaurants and bars inside of the hotel chains. Point-of-sale based malware has driven most of the credit card breaches over the past two years, including intrusions at Target and Home Depot, as well as breaches at a slew of point-of-sale vendors. The malware usually is installed via hacked remote administration tools. Once the attackers have their malware loaded onto the point-of-sale devices, they can remotely capture data from each card swiped at that cash register.

Thieves can then sell that data to crooks who specialize in encoding the stolen data onto any card with a magnetic stripe, and using the cards to purchase high-priced electronics and gift cards from big-box stores like Target and Best Buy.

Readers should remember that they’re not liable for fraudulent charges on their credit or debit cards, but they still have to report the unauthorized transactions. There is no substitute for keeping a close eye on your card statements. Also, consider using credit cards instead of debit cards; having your checking account emptied of cash while your bank sorts out the situation can be a hassle and lead to secondary problems (bounced checks, for instance).
Top

Before You Pay that Ransomware Demand…

Postby BrianKrebs via Krebs on Security »

A decade ago, if a desktop computer got infected with malware the chief symptom probably was an intrusive browser toolbar of some kind. Five years ago you were more likely to get whacked by a banking trojan that stole all your passwords and credit card numbers. These days if your mobile or desktop computer is infected what gets installed is likely to be “ransomware” — malicious software that locks your most prized documents, songs and pictures with strong encryption and then requires you to pay for a key to unlock the files.

Here’s some basic advice about where to go, what to do — and what not to do — when you or someone you know gets hit with ransomware.

Image: nomoreransom.org
First off — breathe deep and try not to panic. And don’t pay the ransom.

True, this may be easier said than done: In many cases the ransom note that hijacks the victim’s screen is accompanied by a digital clock ominously ticking down the minutes and seconds from 72 hours. When the timer expires, the ransom demand usually goes up or even doubles. Continue to ignore the demands and your files will be gone, kaput, nil, nyet, zilch, done forever, warns the extortion message.

See, the key objective of ransomware is a psychological one — to instill fear, uncertainty and dread in the victim — and to sow the conclusion in the victim’s mind that any solution for restoring full access to all his files involves paying up. Indeed, paying the ransom is often the easiest, fastest and most complete way of reversing a security mistake, such as failing to patch, opening a random emailed document e.g., or clicking a link that showed up unbidden in instant message. Some of the more advanced and professional ransomware operations have included helpful 24/7 web-based tech support.

The ransom note from a recent version of the “Locky” ransomware variant. Image: Bleepingcomputer.com.
Paying up is certainly not the cheapest option. The average ransom demanded is approximately $722, according to an analysis published in September by Trend Micro. Interestingly, Trend found the majority of organizations that get infected by ransomware end up paying the ransom. They also found three-quarters of companies which had not suffered a ransomware infection reported they would not pay up when presented with a data ransom demand. Clearly, people tend to see things differently when they’re the ones in the hot seat.

And for those not yet quite confident in the ways of Bitcoin (i.e. most victims), paying up means a crash course in acquiring the virtual currency known as Bitcoin. Some ransomware attackers are friendlier than others in helping victims wade through the process of setting up an account to handle Bitcoin, getting it funded, and figuring out how to pay other people with it. Others just let you figure it all out. The entire ordeal is a trial by fire for sure, but it can also be a very expensive, humbling and aggravating experience.

In the end the extortionist may bargain with you if they’re in a good mood, or if you have a great sob story. But they still want you to know that your choice is a binary one: Pay up, or kiss your sweet files goodbye forever.

This scenario reminds me of the classic short play/silent movie about the villainous landlord and the poor young lady who can’t pay the rent. I imagine the modern version of this play might go something like…

Villain: You MUST pay the ransom!

Victim: I CAN’T pay the ransom!

Villain: You MUST pay the ransom!

Victim: I CAN’T pay the ransom!

Hero: I’ll pay the ransom!

Victim: Oh! My hero!

Villain: Curses! Foiled again!

Okay, nobody’s going to pay the ransomware demand for you (that’s only in Hollywood!). But just like the hero in the silent movie, there are quite a few people out there who are in fact working hard to help victims avoid paying the ransom (AND get their files back to boot).

Assuming you don’t have a recent backup you can restore, fear not: With at least some strains of ransomware, the good guys have already worked out a way to break or sidestep the encryption, and they’ve posted the keys needed to unlock these malware variants free of charge online.

But is the strain that hit your device one that experts already know how to crack? 

WHERE TO GO?

The first place victims should look to find out is nomoreransom.org, a site backed by security firms and cybersecurity organizations in 22 countries. Since its launch on July 25, 2016, nomoreransom.org estimates that it has been able to save 6,000 victims of ransomware more than $2 million USD to date. Last week the group announced the site is now available in Dutch, French, Italian, Portuguese and Russian.



Visit the Crypto Sheriff page at nomoreransom.org, upload one of the files encrypted by the ransomware, and the site will let you know if there is a solution available to unlock all of your files for free.

Another destination that may be useful for ransomware victims is bleepingcomputer.com, which has an excellent Ransomware Help and Tech Support section that is quite useful and may save you a great deal of time and money. But please don’t just create an account here and cry for help. Your best bet is to read the “pinned” notes at the top of that section and follow the instructions carefully.

Chances are, whoever responds to your request will want you to have run a few tools to help identify which strain of ransomware hit your system before agreeing to help. So please be patient and be kind, and remember that if someone decides to help you here they are likely doing so out of their own time and energy.

Bleepingcomputer.com’s ransomware guide.

HOW NOT TO BE THE NEXT RANSOMWARE VICTIM

Regularly backup your data, and make sure the backups are not connected to the computers and networks they are backing up. Most ransomware variants can encrypt files on any attached drives or network files that are also accessible to the host machine (including cloud hosting and cloud-based backups if those passwords are stored on the machine). Bleepingcomputer’s Lawrence Abrams just published this a nice primer called How to Protect and Harden a Computer Against Ransomware.

Many companies are now selling products that claim to block ransomware attacks. Those claims are beyond the scope of this article, but don’t be lulled into thinking these products will always protect you.

Even products that could somehow block all ransomware attacks can’t prevent the biggest reason that ransomware attacks succeed: They trick victims into taking an action that inadvertently undermines the security of their device — be it a smart phone, tablet or desktop computer.

This usually involves clicking a link or downloading and opening a file that arrives in an email or instant message. In either case, it is an action that opens the door to the attacker to download and install malware.

Remember my Three Rules of Online Security:

…For Online Safety.
1: If you didn’t go looking for it, don’t install it.

2: If you installed it, update it.

3: If you no longer need it (or, if it’s become too big of a security risk) get rid of it.

These rules apply no matter what device you use to get online, but I’ll add a few recommendations here that are more device-specific. For desktop users, some of the biggest risks come from insecure browser plugins, as well as malicious Microsoft Office documents and “macros” sent via email and disguised as invoices or other seemingly important, time-sensitive documents.

Microsoft has macros turned off by default in most modern Office versions because they allow attackers to take advantage of resources on the target’s computer that could result in running code on the system. So understand that responding affirmatively to an “Enable Macros?” prompt in an Office document you received externally and were not expecting is extremely risky behavior.

Enterprises can use a variety of group policy changes to harden their defenses against ransomware attacks, such as this one which blocks macros from opening and automatically running in Office programs on Windows 10. Other ransomware-specific group policy guides are here, here and here (happy to add more “here’s” here if they are worthy, let me know).

Also, get rid of or hobble notoriously insecure, oft-targeted browser plugins that require frequent security updates — like Java and Flash. If you’re not good about updating these programs frequently, you may fall victim to an exploit kit that delivers ransomware. Exploit kits are malicious programs made to be stitched into hacked or malicious Web sites. People who visit these sites or who are redirected to them and who are browsing the Web with an outdated version of Flash or Java can have malware automatically and quietly installed.

Mobile users in general need to spend just a tiny fraction more time discerning the origin and reputation of the applications they wish to install, as mobile ransomware variants tend to mimic or even piggyback on popular games and applications found in app stores and other places. Don’t just download the first app that matches your search. And always download from the original source whenever possible to ensure you’re not getting a copycat, counterfeit or malicious version of the game or application that you’re seeking.

For more tips on how not to become the next ransomware victim, check out the bottom half of the FBI’s most recent advisory on the topic.
Top

SELinux System Administration, 2nd Edition

Postby Sven Vermeulen via Simplicity is a form of art... »

While still working on a few other projects, one of the time consumers of the past half year (haven't you noticed? my blog was quite silent) has come to an end: the SELinux System Administration - Second Edition book is now available. With almost double the amount of pages and a serious update of the content, the book can now be bought either through Packt Publishing itself, or the various online bookstores such as Amazon.

With the holidays now approaching, I hope to be able to execute a few tasks within the Gentoo community (and of the Gentoo Foundation) and get back on track. Luckily, my absence was not jeopardizing the state of SELinux in Gentoo thanks to the efforts of Jason Zaman.
Top

Report: $3-5M in Ad Fraud Daily from ‘Methbot’

Postby BrianKrebs via Krebs on Security »

New research suggests that an elaborate cybercrime ring is responsible for stealing between $3 million and $5 million worth of revenue from online publishers and video advertising networks each day. Experts say the scam relies on a vast network of cloaked Internet addresses, rented data centers, phony Web sites and fake users made to look like real people watching short ad segments online.

Online advertising fraud is a $7 billion a year problem, according to AdWeek. Much of this fraud comes from hacked computers and servers that are infected with malicious software which forces the computers to participate in ad fraud. Malware-based ad fraud networks are cheap to acquire and to run, but they’re also notoriously unstable and unreliable because they are constantly being discovered and cleaned up by anti-malware companies.

Now researchers say they’ve uncovered a new class of ad robot or “bot” fraud that was designed from the ground up to keep its nose clean — running not on infected hosts but instead distributed across a vast, rented network of dedicated Web servers and computers.

The Methbot ad fraud infrastructure. Image: White Ops.
According to White Ops, a digital advertising security company based in New York City, those rented computers are connected to a network of more than 570,000 Internet addresses apparently leased or hijacked from various sources.

White Ops dubbed the video ad fraud network “Methbot,” and says the individuals at the helm of this network are spending upwards of $200,000 a month just maintaining a fully automated fraud network that imitates real Web site publishers showing real viewers video-based advertisements.

Ryan Castellucci, principal security researcher at White Ops, said Methbot’s coders built many of the fraud network’s tools from scratch — including the Web browser that each rented computer in the network uses to mimic Web sites displaying video ads. Spoofing actual news Web sites and other popular video-rich destinations, Methbot requests video ads from ad networks, and serves the ads to a vast array of bots that “watch” the videos.

To make each Web browsing session appear more like one generated by a human, Methbot simulates cursor clicks and mouse movements, and even forges social network login information so that it appears the user who viewed the ad was logged in to a social network at the time.

“They’ve written their own browser from scratch in Javascript, and this allows them to arbitrarily control the information that gets fed back to the ad networks and to companies like us who try to detect this stuff,” Castellucci said. “This has allowed Methbot to scale to beyond anything the industry has seen before, putting it in a new class of ad fraud.”

Interestingly, the registration records for virtually all of those Internet addresses have been forged so they appear to be controlled by some of the world’s largest Internet service providers (ISPs).

For instance, one of the many Internet addresses White Ops says was used by Methbot — 196.62.126*117 — is registered in October 2015 to AT&T Services Inc., but the contact address is “adw0rd.yandex.ru@gmail.com” (the letter “o” is a zero). Adw0rd is no doubt a play on Google Adwords, an online advertising service where advertisers pay to display brief advertising copy to Web users.

Another address tied to Methbot — 196.62.3*117 — is registered to the same adw0rd.yandex.ru@gmail.com account but also to “Comcast Cable Communications, Inc.” Records for another Methbot IP — 161.8.252.* — says the address is owned by “Verizon Trademark Services LLC.

Whoever dreamed up Methbot clearly spent a great deal of time and money building the fraud machine. For example, White Ops says the address space alone used by this ad fraud operation has a current market value of approximately $4 million. A full list of the 570,000+ Internet addresses used by Methbot is published in the White Ops report page.

“Methbot operators invested significant time, research, development, and resources to build infrastructure designed to remove these limitations and provide them with unlimited scale,” White Ops said in its report. “They created dedicated data centers to support proxy networks in order to hide the single origin source of their operation. This is the first time we’ve seen data centers impersonating residential internet connections. This makes the scale of this operation virtually unlimited, with none of the typical durability issues of maintaining a constant base of infected user machines.”

Methbot is thought to have helped steal quite a bit more ad revenue than malware-based ad bots that came before it. Source: White Ops.
White Ops said it estimated the earning potential of Methbot by looking at the number of phony video ad impressions it could serve up and the average cost to advertisers for displaying those ads. Assuming an average CPM (cost per mille, or per thousand number of impressions) of $13, the company estimates Methbot has the ability to serve between more than 300 million impressions each day, with a daily revenue ranging from $2.6 million to $5.2 million.

WHO RUNS METHBOT?

White Ops’s report doesn’t delve much into the possible actors behind this ad fraud network, but there are a couple of tantalizing clues in their findings. White Ops found that the Methbot network originally used a program called Zombie to test the ad code in a simulated Web browser environment, but that later the Methbot team built their own Javascript-based browser. The report also notes that Methbot employs a program called “Cheerio” to parse the HTML rendered by the video ads.

Both Zombie and Cheerio show up in this October 2015 discussion thread on the Russian-language tech forum pyha[dot]ru. That thread was started by a developer using the nickname “adw0rd,” the same nickname listed in the phony ISP internet address ranges used by Methbot. A glance at adw0rd’s profile on pyha[dot]ru shows the user is from St. Petersburg, Russia and that his email is adw0rd@pyha.ru.

The “contact” page for adw0rd[dot]com (again, with a zero) includes that same email address, and says the account belongs to a software developer named Mikhail Andreev. That page at adw0rd.com says Andreev also has the account “adw0rd” on Facebook, GoogleTwitter, LinkedIn, Github and Vkontakte (a Russian version of Facebook). A look back at programming projects dating to 2008 for adw0rd can be found via archive.org. Andreev did not respond to requests for comment.

The “abuse” contact email address listed on many of the Internet address ranges that White Ops tied to Methbot was “stepanenko.aa@mmk.ru,” someone who appears to have at least at one time acted as a broker of Internet addresses. That same “stepanenko” email address also appears on the official contacts page for an Alexey A. Stepanenko, senior manager of support group IT management systems within the telecommunications infrastructure at Magnitogorst Iron & Steel Works, the third largest steel company in Russia.

Update, Dec. 23, 1:54 p.m. ET: Fixed a typo in the number of ad impressions White Ops said Methbot was able to produce daily.
Top

This week in VC4 (2016-12-19): DSI, SDTV

Postby Eric Anholt via anholt's lj »

Two big successes last week.

One is that Dave Airlie has pulled Boris's VEC (STDV) code for 4.10.  We didn't quite make it for getting the DT changes in time to have full support in 4.10, but the DT changes will be a lot easier to backport than the driver code.

The other is that I finally got the DSI panel working, after 9 months of frustrating development.  It turns out that my DSI transactions to the Toshiba chip aren't working, but if I use I2C to the undocumented Atmel microcontroller to relay to the Toshiba in one of the 4 possible orderings of the register sequence, the panel comes up.  The Toshiba docs say I need to do I2C writes at the beginning of the poweron sequence, but the closed firmware uses DSI transactions for the whole sequence, making me suspicious that the Atmel has already done some of the Toshiba register setup.

I've now submitted the DSI driver, panel, and clock patches after some massive cleanup.  It even comes with proper runtime power management for both the panel and the VC4 DSI module.

The next steps in modesetting land will be to write an input driver for the panel, do any reworks we need from review, and get those chunks merged in time for 4.11.  While I'm working on this, Boris is now looking at my HDMI audio code so that hopefully we can get that working as well.  Eben is going to poke Dom about fixing the VC4driver interop with media decode.  I feel like we're now making rapid progress toward feature parity on the modesetting side of the VC4 driver.
Top

x8dtu

Postby Dan Langille via Dan Langille's Other Diary »

Please meet x8dtu, a server destined to be the future home of FreshPorts. There is nothing installed here. In short: FreeBSD 11 booting off a mirroed pair of zfsroot SSDs 4.5TB of mirrored ZFS 196612 MB of RAM (yeah, that’s 196GB of RAM) Supermicro X8TDU motherboard Intel Xeon E5620 @ 2.40GHz (two of those, giving [...]
Top

My Yahoo Account Was Hacked! Now What?

Postby BrianKrebs via Krebs on Security »

Many readers are asking what they should be doing in response to Yahoo‘s disclosure Wednesday that a billion of its user accounts were hacked. Here are a few suggestions and pointers, fashioned into a good old Q&A format.

Image: eff.org
Q: Was my account hacked? 

A: Experts I’ve spoken to believe Yahoo has about a billion active accounts. So, yes, it’s very likely your account’s password is compromised, and probably most of the other information you at one point entrusted to Yahoo. According to a statement from the company, the stolen user account information may have included names, email addresses, telephone numbers, dates of birth, hashed passwords (using MD5) and, in some cases, encrypted or unencrypted security questions and answers.”

Q: I’m not sure if I have a Yahoo account. How do I find out? 

A: This is a surprisingly complex question. Thanks to the myriad mergers and business relationships that Yahoo has forged over the years, you may have a Yahoo account and not realize it. That’s because many accounts that are managed through Yahoo don’t actually end in “yahoo.com” (or yahoo. insert country code here).

For example, British telecom giant BT uses Yahoo for their customer email, as did/do SBCGlobalAT&T and BellSouth. Also, Verizon.net email addresses were serviced by Yahoo until AOL took over. Up in Canada, Rogers customers may also have Yahoo email addresses. I’m sure there are plenty of others I’m missing, but you get the point: Your Yahoo account may not include the word “yahoo” at all in the address.

Q: I created a Yahoo account a few years ago, but Yahoo says it doesn’t exist anymore. What’s going on here? 

A: Yahoo has a policy of deactivating or deleting accounts that remain dormant for more than a year. If you haven’t touched your account in years, that’s probably why.

Q: Why would someone want to hack my email account? What could they do with it? 

A: Spam, spam, and spam. Oh, and spam. They want to spam your contacts with malware and ads for dodgy products and services. Also, it gives the bad guys direct access to any account that you have signed up for using that email address. Why? Because if the crooks have access to your inbox, they can request a password reset link be sent to your inbox from any Web site you’ve signed up with at that email address.

For more detail on why these lowlifes might want control over your inbox and how they can monetize that access, see one of the most-read pieces on this blog — The Value of a Hacked Email Account. NB: Accounts that are hijacked for use in spam campaigns may also be suspended or deleted by Yahoo.

Q: What the heck is an MD5?

A: It’s an inferior password storage method that too many companies still use to protect user passwords. An MD5 “hash” is computed by taking your plain text password and running it against an algorithm that is supposed to make the output impossible to reverse. For example, the world’s worst password — “password” — always computes to the MD5 hash of “cc3a0280e4fc1415930899896574e118” (see this MD5 generator for more examples).

The problem is that computing power is super cheap nowadays, and MD5s are no match for brute-force attacks that simply compare the result of hashed dictionary words and other common passwords with user password databases stored in MD5 format (i.e., if the MD5 your email provider stores for you is “cc3a0280e4fc1415930899896574e118”, then congrats on using the world’s worst password).

Long story short, there are vast indexes of these pre-computed MD5 hashes — known as “rainbow tables” — freely available online that can be used to quickly crack a large percentage of any MD5 password list.

Q: So if using hashing methods like MD5 is such a lame security idea, why is Yahoo still doing this? 

A: Yahoo says this breach dates back to 2013. To its credit, Yahoo began moving away from using MD5s for new accounts in 2013 in favor of Bcrypt, far more secure password hashing mechanism. But yeah, even by 2013 anyone with half a clue in securing passwords already long ago knew that storing passwords in MD5 format was no longer acceptable and altogether braindead idea. It’s one of many reasons I’ve encouraged my friends and family to ditch Yahoo email for years.

Q: I’ve been using Yahoo for years. If this service can’t be trusted, what would you recommend? 

A: I’ve used Google Mail (Gmail) for more than a decade, but your mileage may vary. I moved virtually all of my email activity to Gmail years ago mainly because they were among the first to offer more robust authentication and security measures, such as two-step authentication. And they continue to innovate in this space. If you’d like to migrate the messages from your Yahoo account to a Gmail account, see these instructions.

Q: Yahoo said in some cases encrypted or unencrypted security questions and answers were stolen. Why is this a big deal?

A: Because for years security questions have served as convenient backdoors used by criminals to defraud regular, nice people whose only real crime is that they tend to answer questions honestly. But with the proliferation of data that many people post online about themselves on social media sites — combined with the volume of public records that are indexed by various paid and free services — it’s never been easier for a stranger to answer your secret question, “What was the name of your elementary school?”

Don’t feel bad if you naively answered your secret questions honestly. Even criminals get their accounts hacked via easily-guessed secret questions, as evidenced by this story about the San Francisco transit extortionist who last month had his own account hacked via weak secret questions.

Q: So should I change my secret questions in my Yahoo account? Yahoo says it has “invalidated unencrypted security questions and answers so that they cannot be used to access an account,” but how do I know whether my security questions were encrypted or not?

A: Assuming you still can, yes by all means change the answers to the security questions to something only you know. However, it’s not clear that this is still an option: I tried logging in using the secret questions on two older accounts I have and did not see that option available anymore, so it’s likely that Yahoo has disabled them altogether. Yahoo’s statement on this matter is confusing, and the company hasn’t responded yet to follow-up questions to clarify things.

More importantly, if you have used these questions and answers at other sites, please change those answers at the other sites now. Pro tip: If you must patronize sites that allow password and account recovery via secret questions, don’t answer the secret questions honestly. Pick answers that aren’t obvious and that can’t be found using social media or a search engine.

Q: Yahoo also said that the intruders were able to forge “cookies.” What’s that all about?

A: Yahoo said the attackers had worked out a way to forge cookies, text files that Yahoo places on user computers when they log in. Authentication cookies contain information about the user’s session with Yahoo, and these cookies can contain a great deal of information about the user, such as whether that user has already authenticated to the company’s servers.

The attackers in this case apparently found a way to forge these authentication cookies, which would have granted them to access targeted accounts without needing to supply the account’s password. In addition, a forged cookie could have allowed the attackers to remain logged into the hacked accounts for weeks or indefinitely.

Yahoo’s statement said the company is in the process of notifying the affected account holders, and that it has invalidated the forged cookies.

Q: That sounds pretty bad.

A: Yeah, that’s about as bad as it gets. It’s yet another reason I’m telling people to run away from Yahoo email.

Q: Okay, I don’t need my account anymore, and/or I’ve transferred what I need from that account and no longer want to have an account at Yahoo. Can I delete my account? 

A: Yes, you can delete your account. Yahoo has detailed instructions here. But before you do this, consider whether you have created unique relationships with any other Web sites using this email account. If so, you may lose access to those third-party Web site accounts if you no longer have access to the email inbox you used to create that relationship. Take stock of any third-party Web site user accounts you may have tied to your Yahoo inbox, and if you wish to keep those accounts you’ll probably need to log in to them separately and change the contact email address.

Q: What else should I be concerned about as a result of this latest hack? 

A: Make sure you have not used your Yahoo password at any other sites or online accounts that you value or that hold potentially sensitive information about you. If you have, change the password at those other sites to unique, complex passwords. And stop re-using passwords: It’s probably the leading cause of account compromises.

Also, be on the lookout for an uptick in possibly much more targeted email phishing and malware attacks. When attackers have a lot of details about you (like the ones Yahoo said were stolen in this hack) it makes it much easier for them to craft convincing email lures. Be especially wary of clicking on links or attachments in emails you were not expecting, and never respond to login or password reset requests sent via email that you did not initiate.

If your mobile phone number was associated with your Yahoo account, that number may receive SMS phishing or “smishing” attacks as a result. The standard warning about clicking links applies to unbidden text messages as well.

Enable any and all security measures available to you at your current or new email provider. The most important steps you can take are adding a backup email account that you can use to receive messages or password resets if you somehow lose access to your account (i.e., someone figures out your password and seizes control over your account), and taking advantage of two-step or two-factor authentication. With this new feature enabled, thieves would have to know your username, password, and have access to your mobile device or impersonate you to your mobile provider in order to hijack your account. For more on which providers offer this vital security feature, see twofactorauth.org. If you’re sticking with Yahoo despite all of the above, please make sure to take advantage of their two-step feature, called Yahoo Account Key.
Top

Yahoo: One Billion More Accounts Hacked

Postby BrianKrebs via Krebs on Security »

Just months after disclosing a breach that compromised the passwords for a half billion of its users, Yahoo now says a separate incident has jeopardized data from at least a billion more user accounts. The company also warned attackers have figured out a way to log into targeted Yahoo accounts without even supplying the victim’s password.



On September 22, Yahoo warned that a security breach of its networks affected more than 500 million account holders. Today, the company said it uncovered a separate incident in which thieves stole data on more than a billion user accounts, and that the newly disclosed breach is separate from the incident disclosed in September.

(Update, Dec. 15, 2016: Yahoo users looking for more advice on what to do next should check out the Q&A just published here, My Yahoo Account Was Hacked! Now What?).

“Based on further analysis of this data by the forensic experts, we believe an unauthorized third party, in August 2013, stole data associated with more than one billion user accounts,” Yahoo’s chief information security officer Bob Lord said in a statement the company published Wednesday afternoon. “We have not been able to identify the intrusion associated with this theft.”

The statement says that for “potentially affected accounts, the stolen user account information may have included names, email addresses, telephone numbers, dates of birth, hashed passwords (using MD5) and, in some cases, encrypted or unencrypted security questions and answers.”

In addition, Lord said the attackers had worked out a way to forge “cookies” that Yahoo places on user computers when they log in. Authentication cookies are text files that contain information about the user’s session with Yahoo. Cookies can contain a great deal of information about the user, such as whether that the user has already authenticated to the company’s servers.

The attackers in this case apparently found a way to forge these authentication cookies, which would have granted them to access targeted accounts without needing to supply the account’s password. In addition, a forged cookie could have allowed the attackers to remain logged into the hacked accounts for weeks or indefinitely.

Yahoo’s statement said the company is in the process of notifying the affected account holders, and that it has invalidated the forged cookies.

“We have connected some of this activity to the same state-sponsored actor believed to be responsible for the data theft the company disclosed on September 22, 2016,” Lord said.

Yahoo says users should change their passwords and security questions and answers for any other accounts on which they used the same or similar information used for their Yahoo account. The company is asking users to review their accounts for suspicious activity, and to consider using Yahoo Account Key, a simple authentication tool that eliminates the need to use a password on Yahoo altogether.

For years I have been urging friends and family to migrate off of Yahoo email, mainly because the company appeared to fall far behind its peers in blocking spam and other email-based attacks. But also because of pseudo-security features (like secret questions) that tend to end up weakening the security of accounts. I stand by that recommendation.

Most importantly, if you are reusing your Yahoo password anywhere else, now is a great time to change those passwords. And remember, never reuse your email password (or any other password tied to an account that holds sensitive data about you) at any other site.
Top

New Critical Fixes for Flash, MS Windows

Postby BrianKrebs via Krebs on Security »

Both Adobe and Microsoft on Tuesday issued patches to plug critical security holes in their products. Adobe’s Flash Player patch addresses 17 security flaws, including one “zero-day” bug that is already actively being exploited by attackers. Microsoft’s bundle of updates tackles at least 42 security weaknesses in Windows and associated software.



Half of the dozen patches Microsoft released yesterday earned its “critical” rating, meaning the flaws fixed in the updates could be exploited by malware or miscreants to seize remote control over vulnerable Windows computers without any help from users.

As per usual, the largest share of flaws fixed are in Microsoft’s browsers — Internet Explorer and Edge. Also included in the mix are updates for Microsoft Office and .NET.

According to security firm Shavlik, several of the vulnerabilities fixed with this Microsoft patches were publicly disclosed prior to this week, meaning would-be attackers have had a head start trying to figure out how to exploit them.

As part of a new Microsoft policy that took effect in October, home and business Windows users will no longer be able to pick and choose which updates to install and which to leave for another time. Consumers on Windows 7 Service Pack 1 and Windows 8.1 will henceforth receive what Redmond is calling a “Monthly Rollup,” which addresses both security issues and reliability issues in a single update. The “Security-only updates” option — intended for enterprises and not available via Windows Update —  will only include new security patches that are released for that month. What this means is that if any part of the patch bundle breaks, the only option is to remove the entire bundle (instead of the offending patch, as was previously possible).

It’s important to note that several update types won’t be included in a rollup, including those released for Adobe Flash Player on Tuesday. The latest update brings Flash to v. 24.0.0.186 for Windows and Mac users alike. If you have Flash installed, you should update, hobble or remove Flash as soon as possible. To see which version of Flash your browser may have installed, check out this page.

The smartest option is probably to ditch the program once and for all and significantly increase the security of your system in the process. An extremely powerful and buggy program that binds itself to the browser, Flash is a favorite target of attackers and malware. According to analysis released this month by Recorded Future, Adobe Flash vulnerabilities provided six of the top 10 vulnerabilities used by exploit kits in 2016. Exploit kits are automated tools that criminals stitch into the fabric of hacked or malicious Web sites, so that visitors who visit one of these sites with an outdated version of Flash in their browser can have malware silently installed. For some ideas about how to hobble or do without Flash (as well as slightly less radical solutions) check out A Month Without Adobe Flash Player.

Image: RecordedFuture
If you choose to keep and update Flash, please do it today. The most recent versions of Flash should be available from the Flash home page. Windows users who browse the Web with anything other than Internet Explorer may need to apply this patch twice, once with IE and again using the alternative browser (Firefox, Opera, e.g.).

Chrome and IE should auto-install the latest Flash version on browser restart (users may need to manually check for updates in and/or restart the browser to get the latest Flash version). Chrome users may need to restart the browser to install or automatically download the latest version. When in doubt, click the vertical three dot icon to the right of the URL bar, select “Help,” then “About Chrome”: If there is an update available, Chrome should install it then.

As always, if you experience any issues downloading or installing any of these updates, please leave a note about it in the comments below.
Top

Server freeze – 2014.12.14

Postby Dan Langille via Dan Langille's Other Diary »

The knew server is ‘frozen’ again. This has been happening daily at about O301 UTC each night. See my Twitter feed for background. In this post I will include details as I progress through the data. The server in question is knew (yes, that’s the hostname). dtrace hotkernel I left this running in an ssh [...]
Top

‘Operation Tarpit’ Targets Customers of Online Attack-for-Hire Services

Postby BrianKrebs via Krebs on Security »

Federal investigators in the United States and Europe last week arrested nearly three-dozen people suspected of patronizing so-called “booter” services that can be hired to knock targeted Web sites offline. The global crackdown is part of an effort by authorities to weaken demand for these services by impressing upon customers that hiring someone to launch cyberattacks on your behalf can land you in jail.

On Dec. 9, 2016, the U.S. Federal Bureau of Investigation (FBI) arrested Sean Sharma, a 26-year-old student at the University of California accused of using a booter service to knock a San Francisco chat service company’s Web site offline.

Sharma was one of almost three dozen others across 13 countries who were arrested on suspicion of paying for cyberattacks. As part of a coordinated law enforcement effort dubbed “Operation Tarpit,” investigators here and abroad also executed more than 100 so-called “knock-and-talk” interviews with booter buyers who were quizzed about their involvement but not formally charged with crimes.

Netspoof’s DDoS-for-hire packages. Image: Samsclass.info.
Stresser and booter services leverage commercial hosting services and security weaknesses in Internet-connected devices to hurl huge volleys of junk traffic at targeted Web sites. These attacks, known as “distributed denial-of-service” (DDoS) assaults, are digital sieges aimed at causing a site to crash or at least to remain unreachable by legitimate Web visitors.

“DDoS tools are among the many specialized cyber crime services available for hire that may be used by professional criminals and novices alike,” said Steve Kelly, FBI unit chief of the International Cyber Crime Coordination Cell, a task force created earlier this year by the FBI whose stated mission is to ‘defeat the most significant cyber criminals and enablers of the cyber underground.’ “While the FBI is working with our international partners to apprehend and prosecute sophisticated cyber criminals, we also want to deter the young from starting down this path.”

According to Europol, the European Union’s law enforcement agency, the operation involved arrests and interviews of suspected DDoS-for-hire customers in Australia, Belgium, France, Hungary, Lithuania, the Netherlands, Norway, Portugal, Romania, Spain, Sweden, the United Kingdom, and the U.S. Europol said investigators are only warning one-time users, but aggressively pursuing repeat offenders who frequented the booter services.

“This successful operation marks the kick-off of a prevention campaign in all participating countries in order to raise awareness of the risk of young adults getting involved in cybercrime,” reads a statement released Monday by Europol. “Many do it for fun without realizing the consequences of their actions – but the penalties can be severe and have a negative impact on their future prospects.”

The arrests stemmed at least in part from successes that investigators had infiltrating a booter service operating under the name “Netspoof.” According to the U.K.’s National Crime Agency, Netspoof offered subscription packages ranging from £4 (~USD $5) to £380 (~USD $482) – with some customers paying more than £8,000 (> USD $10,000) to launch hundreds of attacks. The NCA said twelve people were arrested in connection with the Netspoof investigation, and that victims included gaming providers, government departments, internet hosting companies, schools and colleges.

The Netspoof portion of last week’s operation was fueled by the arrest of Netspoof’s founder — 20-year-old U.K. resident Grant Manser. As Bleeping Computer reports, Manser’s business had 12,800 registered users, of which 400 bought his tools, launching 603,499 DDoS attacks on 224,548 targets.

Manser was sentenced in April 2016 to two years youth detention suspended for 18 months, as well as 100 hours of community service. According to BC’s Catalin Cimpanu, the judge in Manser’s case went easy on him because he built safeguards in his tools that prevented customers from attacking police, hospitals and government institutions.

ANALYSIS

As a journalist who has long sought to expose the booter and stresser industry and those behind it, this action has been a long time coming. The past three to four years have witnessed a dramatic increase in the number and sophistication of booter services.

In September 2016, this site was the recipient of a record-sized DDoS attack that knocked this site offline for several days. The attack came hours after a story I wrote about the now-defunct booter service vDOS was punctuated by the arrest of two 18-year-old Israeli men allegedly tied to the business. I was able to track them down because vDOS had been massively hacked, and huge troves of data from the service’s servers were shared with KrebsOnSecurity.

vDOS had been in business for four years, but records about how much the business made were incomplete; only two years’ worth of DDoS customer data was available (the rest had apparently been wiped from the server). But in that two years, the records showed that more than 150,000 customer paid in excess of $600,000 to launch DDoS attacks on targeted sites.

The vDos home page.
The demise of vDOS exposed a worrying trend in DDoS-for-hire attack services: The rise of hyper-powered booter services capable of launching attacks that can disrupt operations at even the largest of Web sites and hosting providers.

Hours after the Septemeber attack swept KrebsOnSecurity offline, the same attackers hit French hosting giant OVH with an even larger DDoS-for-hire attack. On Oct. 21, 2016, Internet infrastructure provider Dyn was hit by a very similar attack. All three attacks involved collections of hacked computers powered by DDoS-based malware called “Mirai.” This malware doesn’t infect Windows computers, but instead worms its way into Linux-based systems that run on many consumer hardware products like wireless routers, security cameras and digital video recorders that are left operating in factory-default (insecure) settings.

Security experts say the crime machine that caused problems for Dyn was not the same one that was used to knock my site offline in September. That’s because at the beginning of October the miscreant responsible for creating Mirai leaked the source code for the malware online. Since then, dozens of new Mirai robot networks or “botnets” have been spotted being used to launch cyberattacks — including the one used to attack Dyn. And in some cases, the criminals at the helm of these weapons of mass disruption are renting out “slices” or shares of the botnet to other crooks, typically at the rate of several thousand dollars per week.

I applaud last week’s actions here in the United States and abroad, as I believe many booter service customers patronize them out of some rationalization that doing so isn’t a serious crime. The typical booter service customer is a teenage male who is into online gaming and is seeking a way to knock a rival team or server offline — sometimes to settle a score or even to win a game. One of the co-proprietors of vDos, for example, was famous for DDoSsing the game server offline if his own team was about to lose — thereby preserving the team’s freakishly high ‘win’ ratios.

But this is a stereotype that glosses over a serious, costly and metastasizing problem that needs urgent attention. More critically, early law enforcement intervention for youths involved in launching or patronizing these services may be key to turning otherwise bright kids away from the dark side and toward more constructive uses of their time and talents before they wind up in jail. I’m afraid that absent some sort of “road to Damascus” moment or law enforcement intervention, a great many individuals who initially only pay for such attacks end up getting sucked into an alluring criminal vortex of digital extortion, easy money and online hooliganism.
Top

Wartungsarbeiten: Serverumzug

Postby johannes via Johannes Formanns Webseite »

Es kann in den kommenden Stunden einige Störungen geben, die Webseite und die restliche Infrastruktur zieht auf einen neuen Server.

Update: Erledigt.
Top

system freezes up with lots of sonewconn Listen queue overflow

Postby Dan Langille via Dan Langille's Other Diary »

I recently added 10 new HDD to a system which already had 10 HDD (now a total of 20). The HDD are split into two zpools: $ zpool list NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT system 27T 22.1T 4.93T - 19% 81% 1.00x ONLINE - tank_data 45.2T 26.3T 19.0T - 37% [...]
Top

‘Avalanche’ Crime Ring Leader Eludes Justice

Postby BrianKrebs via Krebs on Security »

The accused ringleader of a cyber fraud gang that allegedly rented out access to a criminal cloud hosting service known as “Avalanche” is now a fugitive from justice following a bizarre series of events in which he shot at Ukrainian police, was arrested on cybercrime charges and then released from custody.

Gennady Kapkanov. Source: NPU.gov
On Nov. 30, authorities across Europe coordinated the arrest of five individuals thought to be tied to the Avalanche crime gang, in an operation that the FBI and its partners abroad described as an unprecedented global law enforcement response to cybercrime.

According to Ukrainian news outlets, the alleged leader of the gang — 33-year-old Russian Gennady Kapkanov — did not go quietly. Kapkanov allegedly shot at officers with a Kalashnikov assault rifle through the front door as they prepared to raid his home, and then attempted to escape off of his 4th floor apartment balcony.

Ukrainian police arrested Kapkanov and booked him on cybercrime charges. But a judge in the city of Poltava, Ukraine later ordered Kapkanov released, saying the prosecution had failed to file the proper charges (including charges of shooting at police officers), charges which could have allowed authorities to hold him much longer. Ukrainian media reports that police have since lost track of Kapkanov.

Ukraine’s Prosecutor General Yuri Lutsenko is now calling for the ouster of the prosecutor in charge of the case. Meanwhile, the Ukranian authorities are now asking the public for help in re-arresting Kapkanov.

Weapons police say they seized from Kapkanov’s apartment. Source: npu.gov.ua


Built as a criminal cloud-hosting environment that was rented out to scammers, spammers other ne’er-do-wells, Avalanche has been a major source of cybercrime for years. In 2009, when investigators say the fraud network first opened for business, Avalanche was responsible for funneling roughly two-thirds of all phishing attacks aimed at stealing usernames and passwords for bank and e-commerce sites.  By 2011, Avalanche was being heavily used by crooks to deploy banking Trojans.

The U.K.’s National Crime Agency (NCA), says the more recent Avalanche fraud network comprised up to 600 servers worldwide and was used to host as many as 800,000 web domains at a time.

Kapkanov, in blue with his hands over his head, standing on his 4th-floor balcony. Image: npu.gov.ua
Kapkanov’s drivers license lists an address in the United Kingdom. Source: npu.gov.ua.
Top

(CVE-2016-8655) Linux Kernel Local Privilege Escalation Flaw Patch rolling out to Gentoo Sources kernels.

Postby admin via Mike Pagano's Weblog »

Just a quick note that I am walking the patch for CVE-2016-8655 down the gentoo-sources kernels.

Yesterday, I released the following kernels with the patch backported:

sys-kernel/gentoo-sources-4.8.12-r1
sys-kernel/gentoo-sources-4.4.36
sys-kernel/gentoo-sources-4.1.36-r1

Updated: 12/08
Also patched:
sys-kernel/gentoo-sources-3.18.45-r1
sys-kernel/gentoo-sources-3.12.68-r1

Updated 12/09
sys-kernel/gentoo-sources-3.10.104-r1
sys-kernel/gentoo-sources-3.4.113-r1

Updated 12/11
sys-kernel/gentoo-sources-3.14.79-r1

If Alice does not get to the others before me, I will continue to walk down the versions until all of them are patched.

Done.
Top

Researchers Find Fresh Fodder for IoT Attack Cannons

Postby BrianKrebs via Krebs on Security »

New research published this week could provide plenty of fresh fodder for Mirai, a malware strain that enslaves poorly-secured Internet of Things (IoT) devices for use in powerful online attacks. Researchers in Austria have unearthed a pair of backdoor accounts in more than 80 different IP camera models made by Sony Corp. Separately, Israeli security experts have discovered trivially exploitable weaknesses in nearly a half-million white-labeled IP camera models that are not currently sought out by Mirai.

A Sony IPELA camera. Image: Sony.
In a blog post published today, Austrian security firm SEC Consult said it found two apparent backdoor accounts in Sony IPELA Engine IP Cameras  devices mainly used by enterprises and authorities. According to SEC Consult, the two previously undocumented user accounts — named “primana” and “debug” — could be used by remote attackers to commandeer the Web server built into these devices, and then to enable “telnet” on them.

Telnet — a protocol that allows remote logons over the Internet — is the very same communications method abused by Mirai, which constantly scours the Web for IoT devices with telnet enabled and protected by factory-default passwords.

“We believe that this backdoor was introduced by Sony developers on purpose (maybe as a way to debug the device during development or factory functional testing) and not an ‘unauthorized third party’ like in other cases (e.g. the Juniper ScreenOS Backdoor, CVE-2015-7755),” SEC Consult wrote.

It’s unclear precisely how many Sony IP cameras may be vulnerable, but a scan of the Web using Censys.io indicates there are at least 4,250 that are currently reachable over the Internet.

“Those Sony IPELA ENGINE IP camera devices are definitely reachable on the Internet and a potential target for Mirai-like botnets, but of course it depends on the network/firewall configuration,” said Johannes Greil, head of SEC Consult Vulnerability Lab. “From our point of view, this is only the tip of the iceberg because it’s only one search string from the device we have.”

Greil said there are other undocumented functionalities in the Sony IP cameras that could be maliciously used by malware or miscreants, such as commands that can be invoked to distort images and/or video recorded by the cameras, or a camera heating feature that could be abused to overheat the devices.

Sony did not respond to multiple requests for comment. But the researchers said Sony has quietly made available to its users an update that disables the backdoor accounts on the affected devices. However, users still need to manually update the firmware using a program called SNC Toolbox.

Greil said it seems likely that the backdoor accounts have been present in Sony cameras for at least four years, as there are signs that someone may have discovered the hidden accounts back in 2012 and attempted to crack the passwords then. SEC Consult’s writeup on their findings is available here.

In other news, researchers at security firm Cybereason say they’ve found at least two previously unknown security flaws in dozens of IP camera families that are white-labeled under a number of different brands (and some without brands at all) that are available for purchase via places like eBay and Amazon. The devices are all administered with the password “888888,” and may be remotely accessible over the Internet if they are not protected behind a firewall. KrebsOnSecurity has confirmed that while the Mirai botnet currently includes this password in the combinations it tries, the username for this password is not part of Mirai’s current configuration.

But Cybereason’s team found that they could easily exploit these devices even if they were set up behind a firewall. That’s because all of these cameras ship with a factory-default peer-to-peer (P2P) communications capability that enables remote “cloud” access to the devices via the manufacturer’s Web site — provided a customer visits the site and provides the unique camera ID stamped on the bottom of the devices.

Although it may seem that attackers would need physical access to the vulnerable devices in order to derive those unique camera IDs, Cybereason’s principal security researcher Amit Serper said the company figured out a simple way to enumerate all possible camera IDs using the manufacturer’s Web site.

“We reverse engineered these cameras so that we can use the manufacturer’s own infrastructure to access them and do whatever we want,” Serper said. “We can use the company’s own cloud network and from there jump onto the customer’s network.”

Lior Div, co-founder and CEO at Cybereason, said a review of the code built into these devices shows the manufacturer does not appear to have made security a priority, and that people using these devices should simply toss them in the trash.

“There is no firmware update mechanism built into these cameras, so there’s no way to patch them,” Div said. “The version of Linux running on these devices was in some cases 14 years old, and the other code libraries on the devices are just as ancient. These devices are so hopelessly broken from a security perspective that it’s hard to really understand what’s going on in the minds of people putting them together.”

Cybereason said it is not disclosing full technical details of the flaws because it would enable any attacker to compromise them for use in online attacks. But it has published a few tips that should help customers determine whether they have a vulnerable device. For example, the camera’s password (888888) is printed on a sticker on the bottom of the devices, and the UID — also printed on the sticker — starts with one of these text strings:



The sticker on the bottom of the camera will tell you if the device is affected by the vulnerability. Image: Cybereason.
“People tend to look down on IoT research and call it junk hacking,” Cybereason’s Yoav Orot wrote in a blog post about its findings. “But that isn’t the right approach if researchers hope to prevent future Mirai botnet attacks. A smart (insert device here) is still a computer, regardless of its size. It has a processor, software and hardware and is vulnerable to malware just like a laptop or desktop. Whether the device records The Walking Dead or lets you watch your cat while you’re at work, attackers can still own it. Researchers should work on junk hacking because these efforts can improve device security (and consumer security in the process), keep consumer products out of the garbage heap and prevent them from being used to carry out DDoS attacks.”

The discoveries by SEC Consult and Cybereason come as policymakers in Washington, D.C. are grappling with what to do about the existing and dawning surge in poorly-secured IoT devices. A blue-ribbon panel commissioned by President Obama issued a 90-page report last week full of cybersecurity policy recommendations for the 45th President of the United States, and IoT concerns and addressing distributed denial-of-service (DDoS) attacks emerged as top action items in that report.

Meanwhile, Morning Consult reports that U.S. Federal Communications Commission Chairman Tom Wheeler has laid out an unexpected roadmap through which the agency could regulate the security of IoT devices. The proposed certification process was laid out in a response to a letter sent by Sen. Mark Warner (D-Va.) shortly after the IoT-based attacks in October that targeted Internet infrastructure company Dyn and knocked offline a number of the Web’s top destinations for the better part of a day.

Morning Consult’s Brendan Bordelon notes that while Wheeler is set to step down as chairman on Jan. 20, “the new framework could be used to support legislation enhancing the FCC’s ability to regulate IoT devices.”
Top

DDoS, IoT Top Cybersecurity Priorities for 45th President

Postby BrianKrebs via Krebs on Security »

Addressing distributed denial-of-service (DDoS) attacks designed to knock Web services offline and security concerns introduced by the so-called “Internet of Things” (IoT) should be top cybersecurity priorities for the 45th President of the United States, according to a newly released blue-ribbon report commissioned by President Obama.

“The private sector and the Administration should collaborate on a roadmap for improving the security of digital networks, in particular by achieving robustness against denial-of-service, spoofing, and other attacks on users and the nation’s network infrastructure,” reads the first and foremost cybersecurity recommendation for President-elect Donald Trump. “The urgency of the situation demands that the next Administration move forward promptly on our recommendations, working closely with Congress and the private sector.”

The 12-person, non-partisan commission produced a 90-page report (PDF) and recommended as their very first action item that the incoming President “should direct senior federal executives to launch a private–public initiative, including provisions to undertake, monitor, track, and report on measurable progress in enabling agile, coordinated responses and mitigation of attacks on the users and the nation’s network infrastructure.”

The panel said this effort should build on previous initiatives, such as a 2011 program by the U.S. Department of Commerce called the Industry Botnet Group.

“Specifically, this effort would identify the actions that can be taken by organizations responsible for the Internet and communications ecosystem to define, identify, report, reduce, and respond to attacks on users and the nation’s network infrastructure,” the report urged. “This initiative should include regular reporting on the actions that these organizations are already taking and any changes in technology, law, regulation, policy, financial reimbursement, or other incentives that may be necessary to support further action—while ensuring that no participating entity obstructs lawful content, applications, services, or nonharmful devices, subject to reasonable network management.”

The report spans some six major imperatives, including 16 recommendations and 63 associated action items. The second major imperative focuses on IoT security concerns, and urges the federal government and private industry to embark upon a number of initiatives to “rapidly and purposefully to improve the security of the Internet of Things.”

“The Department of Justice should lead an interagency study with the Departments of Commerce and Homeland Security and work with the Federal Trade Commission, the Consumer Product Safety Commission, and interested private sector parties to assess the current state of the law with regard to liability for harm caused by faulty IoT devices and provide recommendations within 180 days,” the panel recommended. “To the extent that the law does not provide appropriate incentives for companies to design security into their products, and does not offer protections for those that do, the President should draw on these recommendations to present Congress with a legislative proposal to address identified gaps, as well as explore actions that could be accomplished through executive order.”

Meanwhile, Morning Consult reports that U.S. Federal Communications Commission Chairman Tom Wheeler has laid out an unexpected roadmap through which the agency could regulate the security of IoT devices. The proposed certification process was laid out in a response to a letter sent by Sen. Mark Warner (D-Va.) shortly after the IoT-based attacks in October that targeted Internet infrastructure company Dyn and knocked offline a number of the Web’s top destinations for the better part of a day.

Morning Consult’s Brendan Bordelon notes that while Wheeler is set to step down as chairman on Jan. 20, “the new framework could be used to support legislation enhancing the FCC’s ability to regulate IoT devices.”

ANALYSIS

It’s nice that this presidential commission placed a special emphasis on IoT and denial-of-service attacks, as these two threats alone are clear and present dangers to the stability of e-commerce and free expression online. However, this report overall reads very much like other blue-ribbon commission reports of years past: The recommendations eschew new requirements in favor of the usual calls for best practices, voluntary guidelines, increasing industry-government information sharing, public/private partnerships, and public awareness campaigns.

One recommendation I would like to have seen in this report is a call for federal legislation that requires U.S.-based hosting providers to block spoofed traffic from leaving their networks.

As I noted in a November 2015 story, The Lingering Mess from Default Insecurity, one major contributor to the massive spike in denial-of-service attacks over the past few years is that far too many ISPs and hosting providers allow traffic to leave their networks that did not originate there. Using well-known attack techniques known as traffic amplification and reflection, an attacker can “reflect” his traffic from one or more third-party machines toward the intended target.

In this type of assault, the attacker sends a message to a third party, while spoofing the Internet address of the victim. When the third party replies to the message, the reply is sent to the victim — and the reply is much larger than the original message, thereby amplifying the size of the attack. According to the latest DDoS report from Akamai, more than half of all denial-of-service attacks in the third quarter of 2016 involved reflection and spoofing.

One basic step that many ISPs and hosting providers can but apparently are not taking to blunt these spoofing attacks involves a network security standard that was developed and released more than a dozen years ago. Known as BCP38, its use prevents abusable resources on an ISP’s network from being leveraged in denial-of-service. BCP38 is designed to filter such spoofed traffic, so that the reflected traffic from the third party never even traverses the network of an ISP that’s adopted the anti-spoofing measures.

However, there are non-trivial economic reasons that many ISPs fail to adopt this best practice. This blog post from the Internet Society does a good job of explaining why many ISPs decide not to implement BCP38. Ultimately, it comes down to cost and to a fear that adoption of this best practice will increase costs and prompt some customers to seek out providers that do not enforce this requirement. In some cases, U.S.-based hosting providers that allow spoofing/reflection have been sought out and recommended among miscreants involved in selling DDoS-for-hire services.

In its Q3 2016 State of the Internet report, Akamai notes that while Chinese ISPs occupy the top two sources of spoofed traffic, several large U.S.-based providers make a showing here as well:

Image: Akamai.
It is true that requiring U.S. hosting providers to block spoofing would not solve the spoofing problem globally. But I believe it’s high time that the United States led by example in this arena, if only because we probably have the most to lose by continued inaction. According to Akamai, more than 21 percent of all denial-of-service attacks originate from the United States. And that number has increased from 17 percent a year ago, Akamai found. What’s more, the U.S. is the most frequent target of these attacks, according to DDoS stats released this year by Arbor Networks.
Top

This week in vc4 (2016-12-05): SDTV, 3DMMES, HDMI audio, DSI

Postby Eric Anholt via anholt's lj »

The Raspberry Pi Foundation recently started contracting with Free Electrons to give me some support on the display side of the stack.  Last week I got to review and release their first big piece of work: Boris Brezillon's code for SDTV support.  I had suggested that we use this as the first project because it should have been small and self contained.  It ended up that we had some clock bugs Boris had to fix, and a bug in my core VC4 CRTC code, but he got a working patch series together shockingly quickly.  He did one respin for a couple more fixes once I had tested it, and it's now out on the list waiting for devicetree maintainer review.  If nothing goes wrong, we should have composite out support in 4.11 (we're probably a week late for 4.10).

On my side, I spent some more time on HDMI audio and the DSI panel.  On the audio side, I'm now emitting the GCP packet for audio mute appropriately (I think), and with some more clocking fixes it's now accepting the audio data at the expected rate.  On the DSI front, I fixed a bit of sequencing and added debugfs for the registers like we have in our other encoders.  There's still no actual audio coming out of HDMI, and only white coming out of the panel.

The DSI situation is making me wish for someone else's panel that I could attach to the connector, so I could see if my bugs are in the Atmel bridge programming or in the DSI driver.

I did some more analysis of 3DMMES's shaders, and improved our code generation, for wins of 0.4%, 1.9%, 1.2%, 2.6%, and 1.2%.  I also experimented with changing the UBO (indirect addressed uniform array) upload path, which showed no effect.  3DMMES's uniform arrays are tiny, though, so it may be a win in some other app later.

I also got a couple of new patches from Jonas Pfeil.  I went through his thread switch delay slots patch, which is pretty close to ready.  He has a similar patch for branching delay slots, though apparently that one isn't showing wins yet in things he's tested.  Perhaps most exciting, though, is that he went and implemented an idea I had dropped on github: replacing our shadow copies of raster textures with a bunch of math in the shader and using general memory loads.  This could potentially fix X performance without a compositor, which we otherwise really don't have a workaround for other than "use a compositor."  It could also improve GL-in-a-window performance: right now all of our DRI surfaces are raster format, because we want to be able to get full screen pageflipping, but that means we do the shadow copy if they aren't fullscreen.  Hopefully this week I'll get a chance to test and review it.
Top

duplicity backup und seine Tücken

Postby bed via Zockertown: Nerten News »

Duplicity macht ja einen guten Job, wenn man wirklich auf die Kleinigkeiten achtet.

Bei mir, also Debian Jessie; Hetzner Backupspace; sftp, gibt es das Problem, dass das Backend paramiko, welches die Defaulteinstellung ist, nicht korrekt funktioniert. Ich verwende das Backend pexpect.

Blöd ist nur, wenn man das in seinem Backupscript als Option eingetragen hat, beim Aufruf der Housekeeping Funktionen remove-older-than und cleanup vergiss, mit anzugeben. Damit funktioniert das Aufräumen nicht und irgendwann ist der BACKUP Space voll und das wars dann mit der Delta Sicherung

Also Anmerkung an mich selbst, wenn man ein Script anpasst, dann auch wirklich einen Zyklus im Log überprüfen und oder das Script Zeile für Zeile angucken

Hier ein paar Einträge die mich beim suchen hoffentlich fündig werden lassen, wenn's noch mal klemmt.

duplicity  --ssh-backend pexpect  cleanup -v9 --force  sftp://user@user.your-backup.de/var
nohup duplicity  --ssh-backend pexpect  remove-all-but-n-full 3 -v8 --force  sftp://user@user.your-backup.de/var
nohup duplicity remove-older-than 2M -v9 --ssh-backend pexpect --force sftp://user@user.your-backup.de/var


Top

Visa Delays Chip Deadline for Pumps To 2020

Postby BrianKrebs via Krebs on Security »

Visa this week delayed by three years a deadline for fuel station owners to install payment terminals at the pump that are capable of handling more secure chip-based cards. Experts say the new deadline — extended from 2017 — comes amid a huge spike in fuel pump skimming, and means fraudsters will have another three years to fleece banks and their customers by installing card-skimming devices at the pump.

Until this week, fuel station owners in the United States had until October 1, 2017 to install chip-capable readers at their pumps. Under previous Visa rules, station owners that didn’t have chip-ready readers in place by then would have been on the hook to absorb 100 percent of the costs of fraud associated with transactions in which the customer presented a chip-based card yet was not asked or able to dip the chip (currently, card-issuing banks eat most of the fraud costs from fuel skimming). The chip card technology standard, also known as EMV (short for Europay, MasterCard and Visa) makes credit and debit cards far more expensive and difficult for thieves to clone.

This week, however, Visa said fuel station owners would have until October 1, 2020 to meet the liability shift deadline.

A Bluetooth-based pump card skimmer found inside of a Food N Things pump in Arizona in April 2016.
“The fuel segment has its own unique challenges, which we recognized when we first set the chip activation date for automated fuel dispensers/pumps (AFDs) two years after regular in-store locations,” Visa said in a statement explaining its decision. “We knew that the AFD segment would need more time to upgrade to chip because of the complicated infrastructure and specialized technology required for fuel pumps. For instance, in some cases, older pumps may need to be replaced before adding chip readers, requiring specialized vendors and breaking into concrete. Furthermore, five years after announcing our liability shift, there are still issues with a sufficient supply of regulatory-compliant EMV hardware and software to enable most upgrades by 2017.”

Visa said fuel pump skimming accounts for just 1.3 percent of total U.S. payment card fraud.

“During this interim period, Visa will monitor AFD fraud trends closely and work with merchants, acquirers and issuers to help mitigate any potential counterfeit fraud exposure at AFDs,” Visa said.

Avivah Litan, a fraud analyst with Gartner Inc., said the deadline shift wasn’t unexpected given how many U.S. fuel stations are behind on costly updates, noting that in some cases it can cost more than $10,000 per pump to accommodate chip card readers. The National Association of Convenience Stores estimates that station operators will spend approximately $30,000 per store to accommodate chip readers, and that the total cost to the fuel industry could exceed $4 billion.

“Some of them you can just replace the payment module inside the pump, but the older pumps will need to be completely removed and replaced,” Litan said. “Gas stations and their unattended pumps have always been an easy target for thieves. The fraud usually migrates to the point of least resistance, and we’re seeing now the fraudsters really moving to targeting unattended stations that haven’t been upgraded.”

The delay comes as some states — particularly in the southern United States — are grappling with major increases in fuel station skimming attacks. In September, KrebsOnSecurity published a detailed look at nine months’ worth of fuel pump skimming incident reports filed by police and regulators in Arizona, which said it saw more fuel station skimming attacks in the month of August 2016 than in all of 2015 combined.

That report about Arizona’s skimmer scourge found that thieves tend to target pumps that are furthest from the pump station and closest to the street. They also favored stations that did not employ basic security measures such as tamper-evident security tape and security cameras.

Crooks involved in fuel pump skimming generally are tied to organized crime gangs, as evidenced by this Nov. 2015 investigation into fuel theft gangs operating in Southern California . The thieves most often use stolen master keys or bribery to gain access to the pumps. Once inside the pumps, the thieves hook up their skimmer to the pump’s card reader and PIN pad. The devices also are connected to the pump’s electric power — so they don’t need batteries and can operate indefinitely. Increasingly, these thieves are installing Bluetooth-based skimmers that can transmit stolen data wirelessly, allowing thieves to avoid taking the risky step of retrieving their skimmer gear.

Some pump skimming devices are capable of stealing debit card PINs as well, so it’s good idea to avoid paying with a debit card at the pump. Armed with your PIN and debit card data, thieves can clone the card and pull money out of your account at an ATM. Having your checking account emptied of cash while your bank sorts out the situation can be a huge hassle and create secondary problems (bounced checks, for instance).

“That’s exactly the sort of advice fuel station owners don’t want given to consumers,” Litan said. “For filling stations, credit is their least favorite form of payment because it’s the most expensive for them, which is why some stations offer lower prices for debit card transactions. But consumers should never use a debit card at a gas station.”

Want to learn more about skimming devices? Check out my series, All About Skimmers.
Top

‘Avalanche’ Global Fraud Ring Dismantled

Postby BrianKrebs via Krebs on Security »

In what’s being billed as an unprecedented global law enforcement response to cybercrime, federal investigators in the United States, United Kingdom and Europe today say they’ve dismantled a sprawling cybercrime machine known as “Avalanche” — a distributed, cloud-hosting network that for the past seven years has been rented out to fraudsters for use in launching countless malware and phishing attacks.

The global distribution of servers used in the Avalanche crime machine. Source: Shadowserver.org
According to Europol, the action was the result of a four-year joint investigation between Europol, Eurojust the FBI and authorities in the U.K. and Germany that culminated on Nov. 30, 2016 with the arrest of five individuals, the seizure of 39 Web servers, and the sidelining of more than 830,000 web domains used in the scheme.

Built as a criminal cloud-hosting environment that was rented out to scammers, spammers other ne’er-do-wells, Avalanche has been a major source of cybercrime for years. In 2009, when investigators say the fraud network first opened for business, Avalanche was responsible for funneling roughly two-thirds of all phishing attacks aimed at stealing usernames and passwords for bank and e-commerce sites.  By 2011, Avalanche was being heavily used by crooks to deploy banking Trojans.

The U.K.’s National Crime Agency (NCA), says the more recent Avalanche fraud network comprised up to 600 servers worldwide and was used to host as many as 800,000 web domains at a time.

“Cyber criminals rented the servers and through them launched and managed digital fraud campaigns, sending emails in bulk to infect computers with malware, ransomware and other malicious software that would steal users’ bank details and other personal data,” the NCA said in a statement released today on the takedown. The criminals used the stolen information for fraud or extortion. At its peak 17 different types of malware were hosted by the network, including major strains with names such as goznym, urlzone, pandabanker and loosemailsniffer.At least 500,000 computers around the world were infected and controlled by the Avalanche system on any given day.”

The Avalanche network was especially resilient because it relied on a hosting method known as fast-flux, a kind of round-robin technique that lets botnets hide phishing and malware delivery sites behind an ever-changing network of compromised systems acting as proxies.

“The complex setup of the Avalanche network was popular amongst cybercriminals, because of the double fast flux technique offering enhanced resilience to takedowns and law enforcement action,” Europol said in its statement.

It’s worth noting here that Avalanche has for many years been heavily favored by crime gangs to deploy Zeus and SpyEye malware variants involved in cleaning out bank accounts for a large number of small to mid-sized businesses. These attacks relied heavily on so-called “money mules,” people willingly or unwittingly recruited into helping fraudsters launder stolen funds.

At the time of the takedown, the Avalanche cybercrime infrastructure spanned more than 180 countries, according to The Shadowserver Foundation, a nonprofit group that helped authorities gain control over the Avalanche domains. Read more on Shadowserver’s role in this effort here.

The Avalanche crime infrastructure. Image: Europol
Top

graphicsmagick: memory allocation failure in MagickRealloc (memory.c)

Postby ago via agostino's blog »

Description:
Graphicsmagick is an Image Processing System.

This is an old memory failure, discovered time ago. The maintainer, Mr. Bob Friesenhahn was able to reproduce the issue; I’m quoting his feedback about:

The problem is that the embedded JPEG data claims to have dimensions 59395×56833 and
this is only learned after we are in the JPEG reader.

But for some reasons (maybe not easy to fix) it is still not fixed.
EDIT: the patch was added but I was not aware of that.

The complete ASan output:

# gm identify $FILE
==12404==ERROR: AddressSanitizer failed to allocate 0xfb8065000 (67511930880) bytes of LargeMmapAllocator (error code: 12)
==12404==Process memory map follows:
	0x000000400000-0x000000522000	/usr/bin/gm
	0x000000722000-0x000000723000	/usr/bin/gm
	0x000000723000-0x000000726000	/usr/bin/gm
	0x000000726000-0x0000013a9000	
	0x00007fff7000-0x00008fff7000	
	0x00008fff7000-0x02008fff7000	
	0x02008fff7000-0x10007fff8000	
	0x600000000000-0x602000000000	
	0x602000000000-0x602000010000	
	0x602000010000-0x603000000000	
	0x603000000000-0x603000010000	
	0x603000010000-0x604000000000	
	0x604000000000-0x604000010000	
	0x604000010000-0x606000000000	
	0x606000000000-0x606000010000	
	0x606000010000-0x607000000000	
	0x607000000000-0x607000010000	
	0x607000010000-0x608000000000	
	0x608000000000-0x608000010000	
	0x608000010000-0x60a000000000	
	0x60a000000000-0x60a000010000	
	0x60a000010000-0x60b000000000	
	0x60b000000000-0x60b000010000	
	0x60b000010000-0x60c000000000	
	0x60c000000000-0x60c000010000	
	0x60c000010000-0x60d000000000	
	0x60d000000000-0x60d000010000	
	0x60d000010000-0x60e000000000	
	0x60e000000000-0x60e000010000	
	0x60e000010000-0x60f000000000	
	0x60f000000000-0x60f000010000	
	0x60f000010000-0x610000000000	
	0x610000000000-0x610000010000	
	0x610000010000-0x611000000000	
	0x611000000000-0x611000010000	
	0x611000010000-0x612000000000	
	0x612000000000-0x612000010000	
	0x612000010000-0x614000000000	
	0x614000000000-0x614000020000	
	0x614000020000-0x616000000000	
	0x616000000000-0x616000020000	
	0x616000020000-0x618000000000	
	0x618000000000-0x618000020000	
	0x618000020000-0x619000000000	
	0x619000000000-0x619000020000	
	0x619000020000-0x61a000000000	
	0x61a000000000-0x61a000020000	
	0x61a000020000-0x61b000000000	
	0x61b000000000-0x61b000020000	
	0x61b000020000-0x61c000000000	
	0x61c000000000-0x61c000020000	
	0x61c000020000-0x61d000000000	
	0x61d000000000-0x61d000020000	
	0x61d000020000-0x61e000000000	
	0x61e000000000-0x61e000020000	
	0x61e000020000-0x621000000000	
	0x621000000000-0x621000020000	
	0x621000020000-0x623000000000	
	0x623000000000-0x623000020000	
	0x623000020000-0x624000000000	
	0x624000000000-0x624000020000	
	0x624000020000-0x625000000000	
	0x625000000000-0x625000030000	
	0x625000030000-0x628000000000	
	0x628000000000-0x628000010000	
	0x628000010000-0x62a000000000	
	0x62a000000000-0x62a000010000	
	0x62a000010000-0x630000000000	
	0x630000000000-0x630000020000	
	0x630000020000-0x640000000000	
	0x640000000000-0x640000003000	
	0x7fcc55fbe000-0x7fcc56027000	/usr/lib64/libjpeg.so.62.2.0
	0x7fcc56027000-0x7fcc56226000	/usr/lib64/libjpeg.so.62.2.0
	0x7fcc56226000-0x7fcc56227000	/usr/lib64/libjpeg.so.62.2.0
	0x7fcc56227000-0x7fcc56228000	/usr/lib64/libjpeg.so.62.2.0
	0x7fcc56228000-0x7fcc56254000	/usr/lib64/GraphicsMagick-1.3.24/modules-Q32/coders/jpeg.so
	0x7fcc56254000-0x7fcc56453000	/usr/lib64/GraphicsMagick-1.3.24/modules-Q32/coders/jpeg.so
	0x7fcc56453000-0x7fcc56454000	/usr/lib64/GraphicsMagick-1.3.24/modules-Q32/coders/jpeg.so
	0x7fcc56454000-0x7fcc56457000	/usr/lib64/GraphicsMagick-1.3.24/modules-Q32/coders/jpeg.so
	0x7fcc56457000-0x7fcc5645b000	
	0x7fcc5645b000-0x7fcc5648c000	/usr/lib64/libpng16.so.16.21.0
	0x7fcc5648c000-0x7fcc5668b000	/usr/lib64/libpng16.so.16.21.0
	0x7fcc5668b000-0x7fcc5668c000	/usr/lib64/libpng16.so.16.21.0
	0x7fcc5668c000-0x7fcc5668d000	/usr/lib64/libpng16.so.16.21.0
	0x7fcc5668d000-0x7fcc5671d000	/usr/lib64/GraphicsMagick-1.3.24/modules-Q32/coders/png.so
	0x7fcc5671d000-0x7fcc5691d000	/usr/lib64/GraphicsMagick-1.3.24/modules-Q32/coders/png.so
	0x7fcc5691d000-0x7fcc5691f000	/usr/lib64/GraphicsMagick-1.3.24/modules-Q32/coders/png.so
	0x7fcc5691f000-0x7fcc56927000	/usr/lib64/GraphicsMagick-1.3.24/modules-Q32/coders/png.so
	0x7fcc56927000-0x7fcc56932000	
	0x7fcc56932000-0x7fcc5cfa4000	/usr/lib64/locale/locale-archive
	0x7fcc5cfa4000-0x7fcc5fdff000	
	0x7fcc5fdff000-0x7fcc5fe08000	/usr/lib64/libltdl.so.7.3.1
	0x7fcc5fe08000-0x7fcc60007000	/usr/lib64/libltdl.so.7.3.1
	0x7fcc60007000-0x7fcc60008000	/usr/lib64/libltdl.so.7.3.1
	0x7fcc60008000-0x7fcc60009000	/usr/lib64/libltdl.so.7.3.1
	0x7fcc60009000-0x7fcc6001e000	/lib64/libz.so.1.2.8
	0x7fcc6001e000-0x7fcc6021d000	/lib64/libz.so.1.2.8
	0x7fcc6021d000-0x7fcc6021e000	/lib64/libz.so.1.2.8
	0x7fcc6021e000-0x7fcc6021f000	/lib64/libz.so.1.2.8
	0x7fcc6021f000-0x7fcc6022e000	/lib64/libbz2.so.1.0.6
	0x7fcc6022e000-0x7fcc6042d000	/lib64/libbz2.so.1.0.6
	0x7fcc6042d000-0x7fcc6042e000	/lib64/libbz2.so.1.0.6
	0x7fcc6042e000-0x7fcc6042f000	/lib64/libbz2.so.1.0.6
	0x7fcc6042f000-0x7fcc604d6000	/usr/lib64/libfreetype.so.6.12.3
	0x7fcc604d6000-0x7fcc606d6000	/usr/lib64/libfreetype.so.6.12.3
	0x7fcc606d6000-0x7fcc606dc000	/usr/lib64/libfreetype.so.6.12.3
	0x7fcc606dc000-0x7fcc606dd000	/usr/lib64/libfreetype.so.6.12.3
	0x7fcc606dd000-0x7fcc60730000	/usr/lib64/liblcms2.so.2.0.6
	0x7fcc60730000-0x7fcc60930000	/usr/lib64/liblcms2.so.2.0.6
	0x7fcc60930000-0x7fcc60931000	/usr/lib64/liblcms2.so.2.0.6
	0x7fcc60931000-0x7fcc60936000	/usr/lib64/liblcms2.so.2.0.6
	0x7fcc60936000-0x7fcc60ac9000	/lib64/libc-2.22.so
	0x7fcc60ac9000-0x7fcc60cc9000	/lib64/libc-2.22.so
	0x7fcc60cc9000-0x7fcc60ccd000	/lib64/libc-2.22.so
	0x7fcc60ccd000-0x7fcc60ccf000	/lib64/libc-2.22.so
	0x7fcc60ccf000-0x7fcc60cd3000	
	0x7fcc60cd3000-0x7fcc60ce9000	/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
	0x7fcc60ce9000-0x7fcc60ee8000	/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
	0x7fcc60ee8000-0x7fcc60ee9000	/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
	0x7fcc60ee9000-0x7fcc60eea000	/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
	0x7fcc60eea000-0x7fcc60ef0000	/lib64/librt-2.22.so
	0x7fcc60ef0000-0x7fcc610f0000	/lib64/librt-2.22.so
	0x7fcc610f0000-0x7fcc610f1000	/lib64/librt-2.22.so
	0x7fcc610f1000-0x7fcc610f2000	/lib64/librt-2.22.so
	0x7fcc610f2000-0x7fcc61109000	/lib64/libpthread-2.22.so
	0x7fcc61109000-0x7fcc61308000	/lib64/libpthread-2.22.so
	0x7fcc61308000-0x7fcc61309000	/lib64/libpthread-2.22.so
	0x7fcc61309000-0x7fcc6130a000	/lib64/libpthread-2.22.so
	0x7fcc6130a000-0x7fcc6130e000	
	0x7fcc6130e000-0x7fcc6140b000	/lib64/libm-2.22.so
	0x7fcc6140b000-0x7fcc6160a000	/lib64/libm-2.22.so
	0x7fcc6160a000-0x7fcc6160b000	/lib64/libm-2.22.so
	0x7fcc6160b000-0x7fcc6160c000	/lib64/libm-2.22.so
	0x7fcc6160c000-0x7fcc6160e000	/lib64/libdl-2.22.so
	0x7fcc6160e000-0x7fcc6180e000	/lib64/libdl-2.22.so
	0x7fcc6180e000-0x7fcc6180f000	/lib64/libdl-2.22.so
	0x7fcc6180f000-0x7fcc61810000	/lib64/libdl-2.22.so
	0x7fcc61810000-0x7fcc61e6e000	/usr/lib64/libGraphicsMagick.so.3.15.0
	0x7fcc61e6e000-0x7fcc6206e000	/usr/lib64/libGraphicsMagick.so.3.15.0
	0x7fcc6206e000-0x7fcc6209f000	/usr/lib64/libGraphicsMagick.so.3.15.0
	0x7fcc6209f000-0x7fcc62125000	/usr/lib64/libGraphicsMagick.so.3.15.0
	0x7fcc62125000-0x7fcc621a0000	
	0x7fcc621a0000-0x7fcc621c2000	/lib64/ld-2.22.so
	0x7fcc6228e000-0x7fcc62317000	
	0x7fcc6231b000-0x7fcc62322000	
	0x7fcc62322000-0x7fcc62329000	/usr/lib64/gconv/gconv-modules.cache
	0x7fcc62329000-0x7fcc6234c000	/usr/share/locale/it/LC_MESSAGES/libc.mo
	0x7fcc6234c000-0x7fcc623b6000	
	0x7fcc623b6000-0x7fcc623c1000	
	0x7fcc623c1000-0x7fcc623c2000	/lib64/ld-2.22.so
	0x7fcc623c2000-0x7fcc623c3000	/lib64/ld-2.22.so
	0x7fcc623c3000-0x7fcc623c4000	
	0x7ffcfee34000-0x7ffcfee55000	[stack]
	0x7ffcfef4c000-0x7ffcfef4e000	[vvar]
	0x7ffcfef4e000-0x7ffcfef50000	[vdso]
	0xffffffffff600000-0xffffffffff601000	[vsyscall]
==12404==End of process memory map.
==12404==AddressSanitizer CHECK failed: /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:183 "((0 && "unable to mmap")) != (0)" (0x0, 0x0)
    #0 0x4c9b3d in AsanCheckFailed /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_rtl.cc:67
    #1 0x4d0673 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:159
    #2 0x4d0861 in __sanitizer::ReportMmapFailureAndDie(unsigned long, char const*, char const*, int, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:183
    #3 0x4d989a in __sanitizer::MmapOrDie(unsigned long, char const*, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix.cc:122
    #4 0x421c2f in __sanitizer::LargeMmapAllocator::Allocate(__sanitizer::AllocatorStats*, unsigned long, unsigned long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1033
    #5 0x421c2f in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback>, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> >, __sanitizer::LargeMmapAllocator >::Allocate(__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> >*, unsigned long, unsigned long, bool, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1302
    #6 0x421c2f in __asan::Allocator::Allocate(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:368
    #7 0x421c2f in __asan::asan_malloc(unsigned long, __sanitizer::BufferedStackTrace*) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:718
    #8 0x4c0201 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:53
    #9 0x7fcc61c6a3f2 in MagickRealloc /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/memory.c:471:18
    #10 0x7fcc61cbb2b0 in OpenCache /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/pixel_cache.c:3155:7
    #11 0x7fcc61cb98fd in ModifyCache /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/pixel_cache.c:2955:18
    #12 0x7fcc61cbee4c in SetCacheNexus /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/pixel_cache.c:3878:7
    #13 0x7fcc61cbf5e1 in SetCacheViewPixels /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/pixel_cache.c:3957:10
    #14 0x7fcc61cbf5e1 in SetImagePixels /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/pixel_cache.c:4023
    #15 0x7fcc56235483 in ReadJPEGImage /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/coders/jpeg.c:1344:9
    #16 0x7fcc61ad3a8a in ReadImage /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/constitute.c:1607:13
    #17 0x7fcc566ed13e in ReadOneJNGImage /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/coders/png.c:3308:17
    #18 0x7fcc566d6f72 in ReadJNGImage /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/coders/png.c:3516:9
    #19 0x7fcc61ad3a8a in ReadImage /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/constitute.c:1607:13
    #20 0x7fcc61ad1a4b in PingImage /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/constitute.c:1370:9
    #21 0x7fcc61a23240 in IdentifyImageCommand /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:8372:17
    #22 0x7fcc61a27786 in MagickCommand /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:8862:17
    #23 0x7fcc61a81740 in GMCommandSingle /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:17370:10
    #24 0x7fcc61a7fce3 in GMCommand /tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:17423:16
    #25 0x7fcc6095661f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #26 0x418cd8 in _init (/usr/bin/gm+0x418cd8)

/usr/bin/gm identify: abort due to signal 6 (SIGABRT) "Abort"...
Affected version:
1.3.25

Fixed version:
1.3.26

Commit fix:
http://hg.code.sf.net/p/graphicsmagick/code/rev/38d0f281e8c8

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00096-graphicsmagick-memalloc-MagickRealloc

Timeline:
2016-10-19: bug discovered and reported privately to upstream
2016-10-21: upstream released a patch
2016-12-01: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

graphicsmagick: memory allocation failure in MagickRealloc (memory.c)

Top

libming: listswf: NULL pointer dereference in dumpBuffer (read.c)

Postby ago via agostino's blog »

Description:
libming is a Flash (SWF) output library. It can be used from PHP, Perl, Ruby, Python, C, C++, Java, and probably more on the way..

A fuzzing revealed a null pointer access in listswf. The bug does not reside in any shared object but if you have a web application that calls directly the listswf binary to parse untrusted swf, then you are affected.

The complete ASan output:

# listswf $FILE
header indicates a filesize of 7917 but filesize is 187
File version: 100
File size: 187
Frame size: (8452,8981)x(-4096,0)
Frame rate: 67.851562 / sec.
Total frames: 16387
 Stream out of sync after parse of blocktype 2 (SWF_DEFINESHAPE). 166 but expecting 23.

Offset: 21 (0x0015)
Block type: 2 (SWF_DEFINESHAPE)
Block length: 0

 CharacterID: 55319
 RECT:  (-2048,140)x(0,-1548):12
 FillStyleArray:  FillStyleCount:     18  FillStyleCountExtended:      0
 FillStyle:  FillStyleType: 0
 RGBA: ( 0, 1,9a,ff)
 FillStyle:  FillStyleType: 7f
 FillStyle:  FillStyleType: b
 FillStyle:  FillStyleType: fb
 FillStyle:  FillStyleType: 82                                                                                                                                                                 
 FillStyle:  FillStyleType: 24                                                                                                                                                                 
 FillStyle:  FillStyleType: 67                                                                                                                                                                 
 FillStyle:  FillStyleType: 67                                                                                                                                                                 
 FillStyle:  FillStyleType: 18                                                                                                                                                                 
 FillStyle:  FillStyleType: 9d                                                                                                                                                                 
 FillStyle:  FillStyleType: 6d                                                                                                                                                                 
 FillStyle:  FillStyleType: d7                                                                                                                                                                 
 FillStyle:  FillStyleType: 97                                                                                                                                                                 
 FillStyle:  FillStyleType: 1                                                                                                                                                                  
 FillStyle:  FillStyleType: 26                                                                                                                                                                 
 FillStyle:  FillStyleType: 1a                                                                                                                                                                 
 FillStyle:  FillStyleType: 17                                                                                                                                                                 
 FillStyle:  FillStyleType: 9a                                                                                                                                                                 
 LineStyleArray:  LineStyleCount: 19                                                                                                                                                           
 LineStyle:  Width: 1722                                                                                                                                                                       
 RGBA: (7a,38,df,ff)                                                                                                                                                                           
 LineStyle:  Width: 42742                                                                                                                                                                      
 RGBA: ( 0, 0, 0,ff)                                                                                                                                                                           
 LineStyle:  Width: 70                                                                                                                                                                         
 RGBA: (10,91,64,ff)                                                                                                                                                                           
 LineStyle:  Width: 37031                                                                                                                                                                      
 RGBA: (e7,c7,15,ff)                                                                                                                                                                           
 LineStyle:  Width: 9591                                                                                                                                                                       
 RGBA: (dc,ee,81,ff)                                                                                                                                                                           
 LineStyle:  Width: 4249                                                                                                                                                                       
 RGBA: ( 0,ee,ed,ff)                                                                                                                                                                           
 LineStyle:  Width: 60909                                                                                                                                                                      
 RGBA: (ed,ed,ed,ff)                                                                                                                                                                           
 LineStyle:  Width: 60909
 RGBA: (ed,ed,ed,ff)
 LineStyle:  Width: 60909
 RGBA: (ed,ed,ed,ff)
 LineStyle:  Width: 60909
 RGBA: (ed,ed,ed,ff)
 LineStyle:  Width: 60909
 RGBA: (ed,ed,ed,ff)
 LineStyle:  Width: 60909
 RGBA: (ed,ed,a7,ff)
 LineStyle:  Width: 42919
 RGBA: (a7,a7,9c,ff)
 LineStyle:  Width: 40092
 RGBA: (9c,9c,9c,ff)
 LineStyle:  Width: 32156
 RGBA: (9c,bc,9c,ff)
 LineStyle:  Width: 33948
 RGBA: (9c,9c,9c,ff)
 LineStyle:  Width: 26404
 RGBA: ( 0, c,80,ff)
 LineStyle:  Width: 42752
 RGBA: (a7, 2, 2,ff)
 LineStyle:  Width: 514
 RGBA: (c6, 2, 0,ff)
 NumFillBits: 11
 NumLineBits: 13
 Curved EdgeRecord: 9 Control(-145,637) Anchor(-735,-1010)
 Curved EdgeRecord: 7 Control(-177,156) Anchor(16,32)
 StyleChangeRecord:
  StateNewStyles: 0 StateLineStyle: 1  StateFillStyle1: 0
  StateFillStyle0: 0 StateMoveTo: 0
   LineStyle: 257
  ENDSHAPE

Offset: 23 (0x0017)
Block type: 864 (Unknown Block Type)
Block length: 23


0000: 64 00 00 00 46 4f a3 12  00 00 01 9a 7f 0b fb 82    d...FO.. .......
0010: 24 67 67 18 9d 6d d7                               $gg..m.



Offset: 48 (0x0030)
Block type: 6 (SWF_DEFINEBITS)
Block length: 23

 CharacterID: 6694

Offset: 73 (0x0049)
Block type: 87 (SWF_DEFINEBINARYDATA)
Block length: 7


0000: ASAN:DEADLYSIGNAL
=================================================================
==27703==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000059d2ff bp 0x7ffe859e6fc0 sp 0x7ffe859e6f50 T0)
==27703==The signal is caused by a READ memory access.
==27703==Hint: address points to the zero page.
    #0 0x59d2fe in dumpBuffer /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/read.c:441:23
    #1 0x51c305 in outputSWF_UNKNOWNBLOCK /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/outputtxt.c:2870:3
    #2 0x51c305 in outputBlock /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/outputtxt.c:2937
    #3 0x527e83 in readMovie /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:277:4
    #4 0x527e83 in main /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:350
    #5 0x7f0186c4461f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #6 0x419b38 in _init (/usr/bin/listswf+0x419b38)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/read.c:441:23 in dumpBuffer
==27703==ABORTING
Affected version:
0.4.7

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00078-libming-nullptr-dumpBuffer

Timeline:
2016-11-24: bug discovered and reported to upstream
2016-12-01: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libming: listswf: NULL pointer dereference in dumpBuffer (read.c)

Top

libming: listswf: heap-based buffer overflow in _iprintf (outputtxt.c)

Postby ago via agostino's blog »

Description:
libming is a Flash (SWF) output library. It can be used from PHP, Perl, Ruby, Python, C, C++, Java, and probably more on the way..

A fuzzing revealed an overflow in listswf. The bug does not reside in any shared object but if you have a web application that calls directly the listswf binary to parse untrusted swf, then you are affected.

The complete ASan output:

# listswf $FILE
header indicates a filesize of 18446744072727653119 but filesize is 165
File version: 128
File size: 165
Frame size: (-4671272,-4672424)x(-4703645,4404051)
Frame rate: 142.777344 / sec.
Total frames: 2696

Offset: 25 (0x0019)
Block type: 67 (Unknown Block Type)
Block length: 24


0000: 00 97 6b ba 06 91 6f 98  7a 38 01 00 a6 e3 80 2c    ..k...o. z8.....,
0010: 77 25 d3 d3 1a 19 80 7f                            w%.....



Offset: 51 (0x0033)
Block type: 24 (SWF_PROTECT)
Block length: 1                                                                                                                                                                                
                                                                                                                                                                                               
=================================================================                                                                                                                              
==3132==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eff1 at pc 0x000000499d10 bp 0x7ffc34a55e10 sp 0x7ffc34a555c0                                                       
READ of size 2 at 0x60200000eff1 thread T0                                                                                                                                                     
    #0 0x499d0f in printf_common /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:545       
    #1 0x499a9d in printf_common /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:545       
    #2 0x49abfa in __interceptor_vfprintf /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1321    
    #3 0x509dd7 in vprintf /usr/include/bits/stdio.h:38:10                                                                                                                                     
    #4 0x509dd7 in _iprintf /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/outputtxt.c:144                                                                                            
    #5 0x51f1f5 in outputSWF_PROTECT /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/outputtxt.c:1873:5                                                                                
    #6 0x51c35b in outputBlock /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/outputtxt.c:2933:4                                                                                      
    #7 0x527e83 in readMovie /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:277:4                                                                                              
    #8 0x527e83 in main /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:350                                                                                                     
    #9 0x7f0f1ff6861f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                        
    #10 0x419b38 in _init (/usr/bin/listswf+0x419b38)                                                                                                                                          
                                                                                                                                                                                               
0x60200000eff1 is located 0 bytes to the right of 1-byte region [0x60200000eff0,0x60200000eff1)                                                                                                
allocated by thread T0 here:                                                                                                                                                                   
    #0 0x4d28f8 in malloc /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64                                                       
    #1 0x59b9ab in readBytes /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/read.c:201:17                                                                                             
    #2 0x592864 in parseSWF_PROTECT /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/parser.c:2668:26                                                                                   
    #3 0x5302cb in blockParse /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/blocktypes.c:145:14                                                                                      
    #4 0x527d4f in readMovie /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:265:11                                                                                             
    #5 0x527d4f in main /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:350                                                                                                     
    #6 0x7f0f1ff6861f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                        
                                                                                                                                                                                               
SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:545 in printf_common                                                                                                                                                                      
Shadow bytes around the buggy address:
  0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9df0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa[01]fa
  0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==3132==ABORTING
Affected version:
0.4.7

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00077-libming-heapoverflow-_iprintf

Timeline:
2016-11-24: bug discovered and reported to upstream
2016-12-01: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libming: listswf: heap-based buffer overflow in _iprintf (outputtxt.c)

Top

libming: listswf: heap-based buffer overflow in parseSWF_RGBA (parser.c)

Postby ago via agostino's blog »

Description:
libming is a Flash (SWF) output library. It can be used from PHP, Perl, Ruby, Python, C, C++, Java, and probably more on the way..

A fuzzing revealed an overflow in listswf. The bug does not reside in any shared object but if you have a web application that calls directly the listswf binary to parse untrusted swf, then you are affected.

The complete ASan output:

# listswf $FILE
header indicates a filesize of 237 but filesize is 191
File version: 6
File size: 191
Frame size: (3493,-4999)x(-5076,9541)
Frame rate: 39.625000 / sec.
Total frames: 33032
 Stream out of sync after parse of blocktype 18 (SWF_SOUNDSTREAMHEAD). 29 but expecting 27.

Offset: 21 (0x0015)
Block type: 18 (SWF_SOUNDSTREAMHEAD)
Block length: 4

  PlaybackSoundRate 5.5 kHz
  PlaybackSoundSize 16 bit
  PlaybackSoundType stereo
  StreamSoundCompression MP3
  StreamSoundRate 44 kHz
  StreamSoundSize error
  StreamSoundType mono
  StreamSoundSampleCount 10838
  LatencySeek 53805

Offset: 27 (0x001b)
Block type: 840 (Unknown Block Type)
Block length: 45


0000: 2c 37 a6 30 3a 29 ab d2  54 6e 8e 88 0a f5 1b 6a    ,7.0:).. Tn.....j
0010: a2 f7 a1 a3 a3 a1 e1 06  70 04 8e 90 82 03 40 47    ........ p.....@G
0020: e0 30 c6 a6 83 57 ac 46  4f 8a 91 76 07             .0...W.F O..v.



Offset: 74 (0x004a)
Block type: 514 (Unknown Block Type)
Block length: 27


0000: b2 05 12 c2 3e 3a 01 20  d8 a7 7d 63 01 11 5c fc    ....>:.  ..}c..\.
0010: 15 8e 90 43 8f 64 8e 58  49 ad 95                   ...C.d.X I..



Offset: 103 (0x0067)
Block type: 297 (Unknown Block Type)
Block length: 20


0000: 27 79 a2 e3 2c 56 2a 2d  d2 2c 37 a6 30 3a 29 ab    'y..,V*- .,7.0:).
0010: d2 54 6e 8e                                        .Tn.


skipping 8 bytes

Offset: 125 (0x007d)
Block type: 42 (SWF_DEFINETEXTFORMAT)
Block length: 8

255 gradients in SWF_MORPHGRADiENT, expected a max of 8=================================================================
==31250==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62400000df10 at pc 0x00000057f342 bp 0x7ffe24b21ef0 sp 0x7ffe24b21ee8
WRITE of size 1 at 0x62400000df10 thread T0
    #0 0x57f341 in parseSWF_RGBA /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/parser.c:66:12
    #1 0x57f341 in parseSWF_MORPHGRADIENTRECORD /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/parser.c:746
    #2 0x57f341 in parseSWF_MORPHGRADIENT /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/parser.c:761
    #3 0x57e25a in parseSWF_MORPHFILLSTYLE /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/parser.c:777:7
    #4 0x58b9b8 in parseSWF_MORPHFILLSTYLES /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/parser.c:804:7
    #5 0x58b9b8 in parseSWF_DEFINEMORPHSHAPE /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/parser.c:2098
    #6 0x5302cb in blockParse /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/blocktypes.c:145:14
    #7 0x527d4f in readMovie /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:265:11
    #8 0x527d4f in main /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:350
    #9 0x7f39cc7da61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #10 0x419b38 in _init (/usr/bin/listswf+0x419b38)

0x62400000df10 is located 0 bytes to the right of 7696-byte region [0x62400000c100,0x62400000df10)
allocated by thread T0 here:
    #0 0x4d2af5 in calloc /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:72
    #1 0x58b90a in parseSWF_MORPHFILLSTYLES /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/parser.c:801:28
    #2 0x58b90a in parseSWF_DEFINEMORPHSHAPE /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/parser.c:2098
    #3 0x5302cb in blockParse /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/blocktypes.c:145:14
    #4 0x527d4f in readMovie /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:265:11
    #5 0x527d4f in main /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:350
    #6 0x7f39cc7da61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289

SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/parser.c:66:12 in parseSWF_RGBA
Shadow bytes around the buggy address:
  0x0c487fff9b90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c487fff9ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c487fff9bb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c487fff9bc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c487fff9bd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c487fff9be0: 00 00[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c487fff9bf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c487fff9c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c487fff9c10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c487fff9c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c487fff9c30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==31250==ABORTING
Affected version:
0.4.7

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00076-libming-heapoverflow-parseSWF_RGBA

Timeline:
2016-11-24: bug discovered and reported to upstream
2016-12-01: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libming: listswf: heap-based buffer overflow in parseSWF_RGBA (parser.c)

Top

libming: listswf: heap-based buffer overflow in parseSWF_DEFINEFONT (parser.c)

Postby ago via agostino's blog »

Description:
libming is a Flash (SWF) output library. It can be used from PHP, Perl, Ruby, Python, C, C++, Java, and probably more on the way..

A fuzzing revealed an overflow in listswf. The bug does not reside in any shared object but if you have a web application that calls directly the listswf binary to parse untrusted swf, then you are affected.

The complete ASan output:

# listswf $FILE
header indicates a filesize of 237 but filesize is 272
File version: 6
File size: 272
Frame size: (-4926252,-2829100)x(-2829100,-2829100)
Frame rate: 166.648438 / sec.
Total frames: 42662

Offset: 25 (0x0019)
Block type: 666 (Unknown Block Type)
Block length: 38


0000: a6 a6 a6 a6 a6 a6 a6 a6  a6 a6 a6 a6 a6 c5 c5 c5    ........ ........
0010: c5 c5 00 02 00 00 19 9a  02 ba 06 80 00 00 fe 38    ........ .......8
0020: 01 00 a6 e3 80 29                                  .....)



Offset: 65 (0x0041)
Block type: 149 (Unknown Block Type)
Block length: 55


0000: dc 20 1c db 31 89 c7 ff  7f 0a d8 97 c5 c5 c5 c5    . ..1... .......
0010: cb c5 ea fc 77 da c5 c5  c5 c5 c5 d3 d3 1a 19 9a    ....w... ........
0020: 7a 38 df f6 a6 e3 80 40  77 a5 e3 00 ba f5 90 6f    z8.....@ w......o
0030: d3 1a 5d f0 59 0e c2                               ..].Y..



Offset: 122 (0x007a)
Block type: 896 (Unknown Block Type)
Block length: 47


0000: 7f 41 41 41 67 67 18 9d  6d ea 3b 3f ff ff ba 06    AAAgg.. m.;?....
0010: 80 00 00 fe 38 01 00 a6  e3 80 29 77 25 dc 20 1c    ....8... ..)w%. .
0020: db 31 89 c7 ff 7f 0a d8  97 c5 c5 c5 c5 a6 2f       .1..... ....../



Offset: 171 (0x00ab)
Block type: 919 (Unknown Block Type)
Block length: 48


0000: ab d2 20 65 ff fe 7f 7f  0b 1c 62 24 67 89 18 79    .. e.. ..b$g..y
0010: a2 e3 2c 61 2a 2d c1 2c  37 a6 2f f0 e5 ab d2 20    ..,a*-., 7./.... 
0020: 65 65 65 65 65 c7 8e cb  0a d8 1b 75 85 c5 c5 03    eeeee... ...u....



Offset: 221 (0x00dd)
Block type: 791 (Unknown Block Type)
Block length: 7


0000: c5 b7 c5 d3 d3 1a 19                               .......


=================================================================
==634==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000efb0 at pc 0x00000058582e bp 0x7fff1ed6df60 sp 0x7fff1ed6df58
WRITE of size 2 at 0x60200000efb0 thread T0
    #0 0x58582d in parseSWF_DEFINEFONT /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/parser.c:1656:29
    #1 0x5302cb in blockParse /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/blocktypes.c:145:14
    #2 0x527d4f in readMovie /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:265:11
    #3 0x527d4f in main /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:350
    #4 0x7fad6007961f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #5 0x419b38 in _init (/usr/bin/listswf+0x419b38)

0x60200000efb1 is located 0 bytes to the right of 1-byte region [0x60200000efb0,0x60200000efb1)
allocated by thread T0 here:
    #0 0x4d28f8 in malloc /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
    #1 0x58532d in parseSWF_DEFINEFONT /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/parser.c:1655:36
    #2 0x5302cb in blockParse /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/blocktypes.c:145:14
    #3 0x527d4f in readMovie /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:265:11
    #4 0x527d4f in main /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/main.c:350
    #5 0x7fad6007961f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289

SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/parser.c:1656:29 in parseSWF_DEFINEFONT
Shadow bytes around the buggy address:
  0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9df0: fa fa fa fa fa fa[01]fa fa fa 00 fa fa fa 07 fa
  0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==634==ABORTING
Affected version:
0.4.7

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00075-libming-heapoverflow-parseSWF_DEFINEFONT

Timeline:
2016-11-24: bug discovered and reported to upstream
2016-12-01: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libming: listswf: heap-based buffer overflow in parseSWF_DEFINEFONT (parser.c)

Top

imagemagick: heap-based buffer overflow in IsPixelGray (pixel-accessor.h) (Incomplete fix for CVE-2016-9556)

Postby ago via agostino's blog »

Description:
imagemagick is a software suite to create, edit, compose, or convert bitmap images.

A fuzz on an updated version which includes the fix for CVE-2016-9556, revealed that the issue is still present.

The complete ASan output:

# identify $FILE
==30875==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x610000007cc0 at pc 0x7f897b123267 bp 0x7fff44a4ba70 sp 0x7fff44a4ba68
READ of size 4 at 0x610000007cc0 thread T0
    #0 0x7f897b123266 in IsPixelGray /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/./MagickCore/pixel-accessor.h:507:30
    #1 0x7f897b123266 in IdentifyImageGray /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickCore/attribute.c:677
    #2 0x7f897b123e2d in IdentifyImageType /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickCore/attribute.c:820:7
    #3 0x7f897b3ca308 in IdentifyImage /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickCore/identify.c:527:8
    #4 0x7f897ab0e591 in IdentifyImageCommand /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickWand/identify.c:336:22
    #5 0x7f897ab85ee6 in MagickCommandGenesis /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickWand/mogrify.c:183:14
    #6 0x50a495 in MagickMain /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/utilities/magick.c:145:10
    #7 0x50a495 in main /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/utilities/magick.c:176
    #8 0x7f89797c061f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #9 0x419d28 in _init (/usr/bin/magick+0x419d28)

0x610000007cc0 is located 0 bytes to the right of 128-byte region [0x610000007c40,0x610000007cc0)
allocated by thread T0 here:
    #0 0x4d3685 in posix_memalign /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:130
    #1 0x7f897b44a619 in AcquireAlignedMemory /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickCore/memory.c:258:7
    #2 0x7f897b15840e in AcquireCacheNexusPixels /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickCore/cache.c:4636:33
    #3 0x7f897b15840e in SetPixelCacheNexusPixels /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickCore/cache.c:4748
    #4 0x7f897b14e891 in GetVirtualPixelsFromNexus /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickCore/cache.c:2629:10
    #5 0x7f897b16d90e in GetCacheViewVirtualPixels /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickCore/cache-view.c:664:10
    #6 0x7f897b122878 in IdentifyImageGray /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickCore/attribute.c:672:7
    #7 0x7f897b123e2d in IdentifyImageType /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickCore/attribute.c:820:7
    #8 0x7f897b3ca308 in IdentifyImage /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickCore/identify.c:527:8
    #9 0x7f897ab0e591 in IdentifyImageCommand /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickWand/identify.c:336:22
    #10 0x7f897ab85ee6 in MagickCommandGenesis /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/MagickWand/mogrify.c:183:14
    #11 0x50a495 in MagickMain /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/utilities/magick.c:145:10
    #12 0x50a495 in main /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/utilities/magick.c:176
    #13 0x7f89797c061f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289

SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/portage/media-gfx/imagemagick-7.0.3.8/work/ImageMagick-7.0.3-8/./MagickCore/pixel-accessor.h:507:30 in IsPixelGray
Shadow bytes around the buggy address:
  0x0c207fff8f40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c207fff8f50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c207fff8f60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c207fff8f70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c207fff8f80: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
=>0x0c207fff8f90: 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa fa fa
  0x0c207fff8fa0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x0c207fff8fb0: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
  0x0c207fff8fc0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c207fff8fd0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
  0x0c207fff8fe0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==30875==ABORTING
Affected version:
7.0.3.8

Fixed version:
N/A

Commit fix:
https://github.com/ImageMagick/ImageMagick/commit/4e8c2ed53fcb54a34b3a6185b2584f26cf6874a3

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00090-imagemagick-heapoverflow-IsPixelGray

Timeline:
2016-12-01: bug re-discovered and reported to upstream
2016-12-01: blog post about the issue
2016-12-02: upstream released a patch

Note:
This bug was found with American Fuzzy Lop.

Permalink:

imagemagick: heap-based buffer overflow in IsPixelGray (pixel-accessor.h) (Incomplete fix for CVE-2016-9556)

Top

libav: multiple crashes from the Undefined Behavior Sanitizer

Postby ago via agostino's blog »

Description:
Libav is an open source set of tools for audio and video processing.

A fuzzing on an updated stable releases with the Undefined Behavior Sanitizer enabled, revealed multiple crashes. At the date I’m releasing this post, upstream didn’t give a response/feedback about.

All issues are reproducible with:

avconv -i $FILE -f null -
More details about:

Affected version / Tested on:
11.8
Output/failure:
/tmp/portage/media-video/libav-11.8/work/libav-11.8/libavcodec/mpegvideo.c:2381:65: runtime error: left shift of negative value -1
/tmp/portage/media-video/libav-11.8/work/libav-11.8/libavcodec/mpegvideo.c:2382:65: runtime error: left shift of negative value -1
/tmp/portage/media-video/libav-11.8/work/libav-11.8/libavcodec/mpegvideo.c:2383:65: runtime error: left shift of negative value -1
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00036-libav-leftshift-mpegvideo

######################################

Affected version / Tested on:
11.8
Output/failure:
/tmp/portage/media-video/libav-11.8/work/libav-11.8/libavcodec/mpegvideo_motion.c:323:47: runtime error: left shift of negative value -1
/tmp/portage/media-video/libav-11.8/work/libav-11.8/libavcodec/mpegvideo_motion.c:331:55: runtime error: left shift of negative value -1
/tmp/portage/media-video/libav-11.8/work/libav-11.8/libavcodec/mpegvideo_motion.c:336:55: runtime error: left shift of negative value -1
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00036-libav-leftshift-mpegvideo

######################################

Affected version / Tested on:
11.8
Output/failure:
/tmp/portage/media-video/libav-11.8/work/libav-11.8/libavcodec/mpegvideo_parser.c:91:65: runtime error: signed integer overflow: 28573696 * 400 cannot be represented in type ‘int’
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00037-libav-signedintoverflow-mpegvideo_parser

######################################

Affected version / Tested on:
11.8
Output/failure:
/tmp/portage/media-video/libav-11.8/work/libav-11.8/libavcodec/mpeg12dec.c:1401:41: runtime error: signed integer overflow: 28573696 * 400 cannot be represented in type ‘int’
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00037-libav-signedintoverflow-mpegvideo_parser

######################################

Affected version / Tested on:
11.8
Output/failure:
/tmp/portage/media-video/libav-11.8/work/libav-11.8/libavcodec/x86/mpegvideo.c:53:18: runtime error: index -1 out of bounds for type ‘uint8_t [64]’
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00038-libav-uint8_t64-outofbounds-mpegvideo

######################################

Affected version / Tested on:
11.8
Output/failure:
/tmp/portage/media-video/libav-11.8/work/libav-11.8/libswscale/x86/swscale.c:189:64: runtime error: signed integer overflow: 65463 * 65537 cannot be represented in type ‘int’
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00039-libav-signedintoverflow-swscale_c

######################################

Affected version / Tested on:
11.8
Output/failure:
/tmp/portage/media-video/libav-11.8/work/libav-11.8/libswscale/utils.c:340:30: runtime error: left shift of negative value -1
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00040-libav-leftshift-utils_c

######################################

Affected version / Tested on:
11.8
Output/failure:

Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00041-libav-leftshift-ituh263dec_c

######################################

Affected version / Tested on:
11.8
Output/failure:
/tmp/portage/media-video/libav-11.8/work/libav-11.8/libavcodec/ituh263dec.c:645:34: runtime error: left shift of negative value -16
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00041-libav-leftshift-ituh263dec_c

######################################

Affected version / Tested on:
11.8
Output/failure:
/tmp/portage/media-video/libav-11.8/work/libav-11.8/libavcodec/get_bits.h:530:5: runtime error: load of null pointer of type ‘int16_t’ (aka ‘short’)
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00042-libav-loadnullptr-get_bits_h

Credit:
These bugs were discovered by Agostino Sarubbo of Gentoo.

Timeline:
2016-11-08: bug discovered and reported to upstream
2016-12-01: blog post about the issue

Note:
These bugs were found with American Fuzzy Lop.

Permalink:

libav: multiple crashes from the Undefined Behavior Sanitizer

Top

New Mirai Worm Knocks 900K Germans Offline

Postby BrianKrebs via Krebs on Security »

More than 900,000 customers of German ISP Deutsche Telekom (DT) were knocked offline this week after their Internet routers got infected by a new variant of a computer worm known as Mirai. The malware wriggled inside the routers via a newly discovered vulnerability in a feature that allows ISPs to remotely upgrade the firmware on the devices. But the new Mirai malware turns that feature off once it infests a device, complicating DT’s cleanup and restoration efforts.

Security experts say the multi-day outage is a sign of things to come as cyber criminals continue to aggressively scour the Internet of Things (IoT) for vulnerable and poorly-secured routers, Internet-connected cameras and digital video recorders (DVRs). Once enslaved, the IoT devices can be used and rented out for a variety of purposes — from conducting massive denial-of-service attacks capable of knocking large Web sites offline to helping cybercriminals stay anonymous online.

An internet-wide scan conducted by Shodan.io suggests there may be as many as five million devices vulnerable to the exploit that caused problems for so many DT customers this week. Image: Badcyber.com
This new variant of Mirai builds on malware source code released at the end of September. That leak came a little more a week after a botnet based on Mirai was used in a record-sized attack that caused KrebsOnSecurity to go offline for several days. Since then, dozens of new Mirai botnets have emerged, all competing for a finite pool of vulnerable IoT systems that can be infected.

Until this week, all Mirai botnets scanned for the same 60+ factory default usernames and passwords used by millions of IoT devices. But the criminals behind one of the larger Mirai botnets apparently decided to add a new weapon to their arsenal, incorporating exploit code published earlier this month for a security flaw in specific routers made by Zyxel and Speedport.

These companies act as original equipment manufacturers (OEMs) that specialize in building DSL modems that ISPs then ship to customers. The vulnerability exists in communications protocols supported by the devices that ISPs can use to remotely manage all of the customer-premises routers on their network.

According to BadCyber.com, which first blogged about the emergence of the new Mirai variant, part of the problem is that Deutsche Telekom does not appear to have followed the best practice of blocking the rest of the world from remotely managing these devices as well.

“The malware itself is really friendly as it closes the vulnerability once the router is infected,” BadCyber noted. “It performs [a] command which should make the device ‘secure,’ until next reboot. The first one closes port 7547 and the second one kills the telnet service, making it really hard for the ISP to update the device remotely.” [For the Geek Factor 5 readership out there, the flaw stems from the way these routers parse incoming traffic destined for Port 7547 using communications protocols known as TR-069].

DT has been urging customers who are having trouble to briefly disconnect and then reconnect the routers, a process which wipes the malware from the device’s memory. The devices should then be able to receive a new update from DT that plugs the vulnerability.

That is, unless the new Mirai strain gets to them first. Johannes Ullrich, dean of security research at The SANS Technology Institute, said this version of Mirai aggressively scans the Internet for new victims, and that SANS’s research has shown vulnerable devices are compromised by the new Mirai variant within five to ten minutes of being plugged into the Internet.

Ullrich said the scanning activity conducted by the new Mirai variant is so aggressive that it can create hangups and crashes even for routers that are are not vulnerable to this exploit.

“Some of these devices went down because of the sheer number of incoming connections” from the new Mirai variant, Ullrich said. “They were listening on Port 7547 but were not vulnerable to this exploit and were still overloaded with the number of connections to that port.”

A Deutsche Telekom Speedport DSL modem.

FEEDING THE CRIME MACHINE

Allison Nixon, director of security research at Flashpoint, said this latest Mirai variant appears to be an attempt to feed fresh victims into one of the larger and more established Mirai botnets out there today.

Nixon said she suspects this particular botnet is being rented out in discrete chunks to other cybercriminals. Her suspicions are based in part on the fact that the malware phones home to a range of some 256 Internet addresses that for months someone has purchased for the sole purpose of hosting nothing but servers used to control multiple Mirai botnets.

“The malware points to some [Internet addresses] that are in ranges which were purchased for the express purpose of running Mirai,” Nixon said. “That range does nothing but run Mirai control servers on it, and they’ve been doing it for a while now. I would say this is probably part of a commercial service because purchasing this much infrastructure is not cheap. And you generally don’t see people doing this for kicks, you see them doing it for money.”

Nixon said the criminals behind this new Mirai variant are busy subdividing their botnet — thought to be composed of several hundred thousand hacked IoT devices — among multiple, distinct control servers. This approach, she said, addresses two major concerns among cybercriminals who specialize in building botnets that are resold for use in huge distributed denial of service (DDoS) attacks.

The first is that extended DDoS attacks which leverage firepower from more bots than are necessary to take down a target host can cause the crime machine’s overall bot count to dwindle more quickly than the botnet can replenish itself with newly infected IoT devices — greatly diminishing the crime machine’s strength and earning power.

“I’ve been watching a lot of chatter in the DDoS community, and one of the topics that frequently comes up is that there are many botnets out there where the people running them don’t know each other, they’ve just purchased time on the botnet and have been assigned specific slots on it,” Nixon said. “Long attacks would end up causing the malware or infected machines to crash, and the attack and would end up killing the botnet if it was overused. Now it looks like someone has architected a response to that concern, knowing that you have to preserve bots as much as you can and not be excessive with the DDoS traffic you’re pushing.”

Nixon said dividing the Mirai botnet into smaller sections which each answer to multiple control servers also makes the overall crime machine more resistant to takedown efforts by security firms and researchers.

“This is an interesting development because a lot of the response to Mirai lately has been to find a Mirai controller and take it down,” Nixon said. “Right now, the amount of redundant infrastructure these Mirai actors have is pretty significant, and it suggests they’re trying to make their botnets more difficult to take down.”

Nixon said she worries that the aggressive Mirai takedown efforts by the security community may soon prompt the crooks to adopt far more sophisticated and resilient methods of keeping their crime machines online.

“We have to realize that the takedown option is not going to be there forever with these IoT botnets,” she said.
Top

San Francisco Rail System Hacker Hacked

Postby BrianKrebs via Krebs on Security »

The San Francisco Municipal Transportation Agency (SFMTA) was hit with a ransomware attack on Friday, causing fare station terminals to carry the message, “You are Hacked. ALL Data Encrypted.” Turns out, the miscreant behind this extortion attempt got hacked himself this past weekend, revealing details about other victims as well as tantalizing clues about his identity and location.

A copy of the ransom message left behind by the “Mamba” ransomware.
On Friday, The San Francisco Examiner reported that riders of SFMTA’s Municipal Rail or “Muni” system were greeted with handmade “Out of Service” and “Metro Free” signs on station ticket machines. The computer terminals at all Muni locations carried the “hacked” message: “Contact for key (cryptom27@yandex.com),” the message read.

The hacker in control of that email account said he had compromised thousands of computers at the SFMTA, scrambling the files on those systems with strong encryption. The files encrypted by his ransomware, he said, could only be decrypted with a special digital key, and that key would cost 100 Bitcoins, or approximately USD $73,000.

On Monday, KrebsOnSecurity was contacted by a security researcher who said he hacked this very same cryptom27@yandex.com inbox after reading a news article about the SFMTA incident. The researcher, who has asked to remain anonymous, said he compromised the extortionist’s inbox by guessing the answer to his secret question, which then allowed him to reset the attacker’s email password. A screen shot of the user profile page for cryptom27@yandex.com shows that it was tied to a backup email address, cryptom2016@yandex.com, which also was protected by the same secret question and answer.

Copies of messages shared with this author from those inboxes indicate that on Friday evening, Nov. 25, the attacker sent a message to SFMTA infrastructure manager Sean Cunningham with the following demand (the entirety of which has been trimmed for space reasons), signed with the pseudonym “Andy Saolis.”

“if You are Responsible in MUNI-RAILWAY !

All Your Computer’s/Server’s in MUNI-RAILWAY Domain Encrypted By AES 2048Bit!

We have 2000 Decryption Key !

Send 100BTC to My Bitcoin Wallet , then We Send you Decryption key For Your All Server’s HDD!!”

One hundred Bitcoins may seem like a lot, but it’s apparently not far from a usual payday for this attacker. On Nov. 20, hacked emails show that he successfully extorted 63 bitcoins (~$45,000) from a U.S.-based manufacturing firm.

The attacker appears to be in the habit of switching Bitcoin wallets randomly every few days or weeks. “For security reasons” he explained to some victims who took several days to decide whether to pay the ransom they’d been demanded. A review of more than a dozen Bitcoin wallets this criminal has used since August indicates that he has successfully extorted at least $140,000 in Bitcoin from victim organizations.

That is almost certainly a conservative estimate of his overall earnings these past few months: My source said he was unable to hack another Yandex inbox used by this attacker between August and October 2016, “w889901665@yandex.com,” and that this email address is tied to many search results for tech help forum postings from people victimized by a strain of ransomware known as Mamba and HDD Cryptor.

Copies of messages shared with this author answer many questions raised by news media coverage of this attack, such as whether the SFMTA was targeted. In short: No. Here’s why.

Messages sent to the attacker’s cryptom2016@yandex.com account show a financial relationship with at least two different hosting providers. The credentials needed to manage one of those servers were also included in the attacker’s inbox in plain text, and my source shared multiple files from that server.

KrebsOnSecurity sought assistance from several security experts in making sense of the data shared by my source. Alex Holden, chief information security officer at Hold Security Inc, said the attack server appears to have been used as a staging ground to compromise new systems, and was equipped with several open-source tools to help find and infect new victims.

“It appears our attacker has been using a number of tools which enabled the scanning of large portions of the Internet and several specific targets for vulnerabilities,” Holden said. “The most common vulnerability used ‘weblogic unserialize exploit’ and especially targeted Oracle Corp. server products, including Primavera project portfolio management software.”

According to a review of email messages from the Cryptom27 accounts shared by my source, the attacker routinely offered to help victims secure their systems from other hackers for a small number of extra Bitcoins. In one case, a victim that had just forked over a 20 Bitcoin ransom seemed all too eager to pay more for tips on how to plug the security holes that got him hacked. In return, the hacker pasted a link to a Web server, and urged the victim to install a critical security patch for the company’s Java applications.

“Read this and install patch before you connect your server to internet again,” the attacker wrote, linking to this advisory that Oracle issued for a security hole that it plugged in November 2015.

In many cases, the extortionist told victims their data would be gone forever if they didn’t pay the ransom in 48 hours or less. In other instances, he threatens to increase the ransom demand with each passing day.

WHO IS ALI REZA?

The server used to launch the Oracle vulnerability scans offers tantalizing clues about the geographic location of the attacker. That server kept detailed logs about the date, time and Internet address of each login. A review of the more than 300 Internet addresses used to administer the server revealed that it has been controlled almost exclusively from Internet addresses in Iran. Another hosting account tied to this attacker says his contact number is +78234512271, which maps back to a mobile phone provider based in Russia.

But other details from the attack server indicate that the Russian phone number may be a red herring. For example, the attack server’s logs includes the Web link or Internet address of each victimized server, listing the hacked credentials and short notations apparently made next to each victim by the attacker. Google Translate had difficulty guessing which language was used in the notations, but a fair amount of searching indicates the notes are transliterated Farsi or Persian, the primary language spoken in Iran and several other parts of the Middle East.

User account names on the attack server hold other clues, with names like “Alireza,” “Mokhi.” Alireza may pertain to Ali Reza, the seventh descendant of the Islamic prophet Muhammad, or just to a very common name among Iranians, Arabs and Turks.

The targets successfully enumerated as vulnerable by the attacker’s scanning server include the username and password needed to remotely access the hacked servers, as well as the IP address (and in some cases domain name) of the victim organization. In many cases, victims appeared to use newly-registered email addresses to contact the extortionist, perhaps unaware that the intruder had already done enough reconnaissance on the victim organization to learn the identity of the company and the contact information for the victim’s IT department.

The list of victims from our extortionist shows that the SFMTA was something of an aberration. The vast majority of organizations victimized by this attacker were manufacturing and construction firms based in the United States, and most of those victims ended up paying the entire ransom demanded — generally one Bitcoin (currently USD $732) per encrypted server.

Emails from the attacker’s inbox indicate some victims managed to negotiate a lesser ransom. China Construction of America Inc., for example, paid 24 Bitcoins (~$17,500) on Sunday, Nov. 27 to decrypt some 60 servers infected with the same ransomware — after successfully haggling the attacker down from his original demand of 40 Bitcoins. Other construction firms apparently infected by ransomware attacks from this criminal include King of Prussia, Pa. based Irwin & LeightonCDM Smith Inc. in Boston; Indianapolis-based Skillman; and the Rudolph Libbe Group, a construction consulting firm based in Walbridge, Ohio. It’s unclear whether any of these companies paid a ransom to regain access to their files.

PROTECT YOURSELF AND YOUR ORGANIZATION

The data leaked from this one actor shows how successful and lucrative ransomware attacks can be, and how often victims pay up. For its part, the SFMTA said it never considered paying the ransom.

“We have an information technology team in place that can restore our systems and that is what they are doing,” said SFMTA spokesman Paul Rose. “Existing backup systems allowed us to get most affected computers up and running this morning, and our information technology team anticipates having the remaining computers functional in the next two days.”

As the SFMTA’s experience illustrates, having proper and regular backups of your data can save you bundles. But unsecured backups can also be encrypted by ransomware, so it’s important to ensure that backups are not connected to the computers and networks they are backing up. Examples might include securing backups in the cloud or physically storing them offline. It should be noted, however, that some instances of ransomware can lock cloud-based backups when systems are configured to continuously back up in real-time.

That last tip is among dozens offered by the Federal Bureau of Investigation, which has been warning businesses about the dangers of ransomware attacks for several years now. For more tips on how to avoid becoming the next ransomware victim, check out the FBI’s most recent advisory on ransomware.

Finally, as I hope this story shows, truthfully answering secret questions is a surefire way to get your online account hacked. Personally, I try to avoid using vital services that allow someone to reset my password if they can guess the answers to my secret questions. But in some cases — as with United Airlines’s atrocious new password system — answering secret questions is unavoidable. In cases where I’m allowed to type in the answer, I always choose a gibberish or completely unrelated answer that only I will know and that cannot be unearthed using social media or random guessing.
Top

This week in vc4 (2016-11-28): performance tuning

Postby Eric Anholt via anholt's lj »

I missed last week's update, but with the holiday it ended up being a short week anyway.

The multithreaded fragment shaders are now in drm-next and Mesa master.  I think this was the last big win for raw GL performance and we're now down to the level of making 1-2% improvements in our commits.  That is, unless we're supposed to be using double-buffer non-MS mode and the closed driver was just missing that feature.  With the glmark2 comparisons I've done, I'm comfortable with this state, though.  I'm now working on performance comparisons for 3DMMES Taiji, which the HW team often uses as a benchmark.  I spent a day or so trying to get it ported to the closed driver and failed, but I've got it working on the open stack and have written a couple of little performance fixes with it.

The first was just a regression fix from the multithreading patch series, but it was impressive that multithreading hid a 2.9% instruction count penalty and still showed gains.

One of the new fixes I've been working on is folding ALU operations into texture coordinate writes.  This came out of frustration from the instruction selection research I had done the last couple of weeks, where all algorithms seemed like they would still need significant peephole optimization after selection.  I finally said "well, how hard would it be to just finish the big selection problems I know are easily doable with peepholes?" and it wasn't all that bad.  The win came out to about 1% of instructions, with a similar benefit to overall 3DMMES performance (it's shocking how ALU-bound 3DMMES is)

I also started on a branch to jump to the end of the program when all 16 pixels in a thread have been discarded.  This had given me a 7.9% win on GLB2.7 on Intel, so I hoped for similar wins here.  3DMMES seemed like a good candidate for testing, too, with a lot of discards that are followed by reams of code that could be skipped, including texturing.  Initial results didn't seem to show a win, but I haven't actually done any stats on it yet.  I also haven't done the usual "draw red where we were applying the optimization" hack to verify that my code is really working, either.

While I've been working on this, Jonas Pfeil (who originally wrote the multithreading support) has been working on a couple of other projects.  He's been trying to get instructions scheduled into the delay slots of thread switches and branching, which should help reduce any regressions those two features might have caused.  More exciting, he's just posed a branch for doing nearest-filtered raster textures (the primary operation in X11 compositing) using direct memory lookups instead of our shadow-copy fallback.  Hopefully I get a chance to review, test, and merge in the next week or two.

On the kernel side, my branches for 4.10 have been pulled.  We've got ETC1 and multithread FS for 4.10, and a performance win in power management.  I've also been helping out and reviewing Boris Brezillon's work for SDTV output in vc4.  Those patches should be hitting the list this week.
Top

ATM Insert Skimmers: A Closer Look

Postby BrianKrebs via Krebs on Security »

KrebsOnSecurity has featured multiple stories about the threat from ATM fraud devices known as “insert skimmers,” wafer-thin data theft tools made to be completely hidden inside of a cash’s machine’s card acceptance slot. For a closer look at how stealthy insert skimmers can be, it helps to see videos of these things being installed and removed. Here’s a look at promotional sales videos produced by two different ATM insert skimmer peddlers.

Traditional ATM skimmers are fraud devices made to be placed over top of the cash machine’s card acceptance slot, usually secured to the ATM with glue or double-sided tape. Increasingly, however, more financial institutions are turning to technologies that can detect when something has been affixed to the ATM. As a result, more fraudsters are selling and using insert skimming devices — which are completely hidden from view once inserted into an ATM.

The fraudster demonstrating his insert skimmer in the short video above spends the first half of the demo showing how a regular bank card can freely move in and out of the card acceptance slot while the insert skimmer is nestled inside. Toward the end of the video, the scammer retrieves the insert skimmer using what appears to be a rather crude, handmade tool thin enough to fit inside a wallet.

A sales video produced by yet another miscreant in the cybercrime underground shows an insert skimmer being installed and removed from a motorized card acceptance slot that has been fully removed from an ATM so that the fraud device can be seen even while it is inserted.

In a typical setup, insert skimmers capture payment card data from the magnetic stripe on the backs of cards inserted into a hacked ATM, while a pinhole spy camera hidden above or beside the PIN pad records time-stamped video of cardholders entering their PINs. The data allows thieves to fabricate new cards and use PINs to withdraw cash from victim accounts.

Covering the PIN pad with your hand blocks any hidden camera from capturing your PIN — and hidden cameras are used on the vast majority of the more than three dozen ATM skimming incidents that I’ve covered here. Shockingly, few people bother to take this simple and effective step, as detailed in this skimmer tale from 2012, wherein I obtained hours worth of video seized from two ATM skimming operations and saw customer after customer walk up, insert their cards and punch in their digits — all in the clear.

Once you understand how stealthy these ATM fraud devices are, it’s difficult to use a cash machine without wondering whether the thing is already hacked. The truth is most of us probably have a better chance of getting physically mugged after withdrawing cash than encountering a skimmer in real life. However, here are a few steps we can all take to minimize the success of skimmer gangs.

-Cover the PIN pad while you enter your PIN.

-Keep your wits about you when you’re at the ATM, and avoid dodgy-looking and standalone cash machines in low-lit areas, if possible.

-Stick to ATMs that are physically installed in a bank. Stand-alone ATMs are usually easier for thieves to hack into.

-Be especially vigilant when withdrawing cash on the weekends; thieves tend to install skimming devices on a weekend — when they know the bank won’t be open again for more than 24 hours.

-Keep a close eye on your bank statements, and dispute any unauthorized charges or withdrawals immediately.

If you liked this piece and want to learn more about skimming devices, check out my series All About Skimmers.
Top

Waiting...

Postby via www.my-universe.com Blog Feed »

Still 14 hours to go before I finally can test X-Plane 11… Well, as you can see, I'm about to give the XP11 Beta a try. At first when XP11 was announced, I thought I'd wait until at least the second or third minor version of XP11, and I wanted to be sure my precious third-party add-ons (worth several hundreds of dollars) do actually work in XP11. However, curiosity finally took over. With more than enough disk space remaining on my SSD RAID 0, I decided to go for XP11 right now. Most certainly I will not run it with the same add-on setup as my XP10 - for the weather stuff I'm thinking about replacing SkyMaxx Pro, RWC and Ventura Sky by xEnviro (or at least have a try), and regarding payware aircrafts, I will definitely only install the ones I use most of the time. But before thinking about enhancements, I shall wait for the installation to complete - and then I'll have a closer look at what XP11 delivers out of the box. Looking forward to tomorrow…

Top

DoD Opens .Mil to Legal Hacking, Within Limits

Postby BrianKrebs via Krebs on Security »

Hackers of all stripes looking to test their mettle can now legally hone their cyber skills, tools and weaponry against any Web property operated by the U.S. Department of Defense (DoD), according to a new military-wide policy for reporting and fixing security vulnerabilities.



Security researchers are often reluctant to report programming flaws or security holes they’ve stumbled upon for fear that the vulnerable organization might instead decide to shoot the messenger and pursue hacking charges.

But on Nov. 21, the DoD sought to clear up any ambiguity on that front for the military’s substantial online presence, creating both a centralized place to report cybersecurity flaws across the dot-mil space as well as a legal safe harbor (and the prospect of public recognition) for researchers who abide by a few ground rules.

The DoD said it would “deal in good faith” with researchers “who discover, test, and submit vulnerabilities or indicators of vulnerabilities in accordance with these guidelines:

“Your activities are limited exclusively to –
(1) Testing to detect a vulnerability or identify an indicator related to a vulnerability; or
(2) Sharing with, or receiving from, DoD information about a vulnerability or an indicator related to a vulnerability.”

The Department of Defense also issued the following ten commandments for demonstrating compliance with its policy:

  1. You do no harm and do not exploit any vulnerability beyond the minimal amount of testing required to prove that a vulnerability exists or to identify an indicator related to a vulnerability.
  2. You avoid intentionally accessing the content of any communications, data, or information transiting or stored on DoD information system(s) – except to the extent that the information is directly related to a vulnerability and the access is necessary to prove that the vulnerability exists.
  3. You do not exfiltrate any data under any circumstances.
  4. You do not intentionally compromise the privacy or safety of DoD personnel (e.g. civilian employees or military members), or any third parties.
  5. You do not intentionally compromise the intellectual property or other commercial or financial interests of any DoD personnel or entities, or any third parties.
  6. You do not publicly disclose any details of the vulnerability, indicator of vulnerability, or the content of information rendered available by a vulnerability, except upon receiving explicit written authorization from DoD.
  7. You do not conduct denial of service testing.
  8. You do not conduct social engineering, including spear phishing, of DoD personnel or contractors.
  9. You do not submit a high-volume of low-quality reports.
  10. If at any point you are uncertain whether to continue testing, please engage with our team.
In return, the DoD said it commits to acknowledging receipt of a report within three business days, and that it will work to confirm the existence of the vulnerability to the researcher and keep the researcher informed of any remediation underway. There are some restrictions, however. For example, researchers who report vulnerabilities will be expected to refrain from publicly disclosing their findings unless and until the DoD provides written consent that it’s okay to do so.

“We want researchers to be recognized publicly for their contributions, if that is the researcher’s desire,” the DoD stated. “We will seek to allow researchers to be publicly recognized whenever possible. However, public disclosure of vulnerabilities will only be authorized at the express written consent of DoD.”

The DoD said if it couldn’t immediately fix or publicly acknowledge reported vulnerabilities, it might be because doing so could have life-or-death consequences for service members.

“Many DoD technologies are deployed in combat zones and, to varying degrees, support ongoing military operations; the proper functioning of DoD systems and applications can have a life-or-death impact on Service members and international allies and partners of the United States,” the agency observed. “DoD must take extra care while investigating the impact of vulnerabilities and providing a fix, so we ask your patience during this period.”

HACK THE ARMY

The Defense Department made the announcement via Hackerone.com, a company that helps organizations build and manage vulnerability reporting policies. HackerOne also helps customers build out “bug bounty” programs that remunerate and recognize researchers who report security flaws.

HackerOne currently is coordinating an upcoming bug bounty program called “Hack the Army,” in which some 500 qualifying contestants can earn cash rewards for finding and reporting cybersecurity weaknesses in the Army’s various online properties (incidentally, Hack the Army runs from Nov. 30 through Dec. 21, 2016, and interested/eligible hackers have until Nov. 28, at 17:00 EST to apply for a shot at one of those 500 spots).

Alex Rice, HackerOne’s co-founder and chief technology officer, said most organizations don’t have an official policy about how they will respond to reports about cybersecurity weaknesses and liabilities, and that the absence of such a policy often discourages researchers from reporting serious security holes.

“The default is terribly unfriendly to researchers,” Rice said. “The Computer Fraud and Abuse Act (CFAA) allows almost any company to go after researchers as hackers, and this happened far too many times. What this does is carve out a safe harbor from the CFAA, and begin to create a safe place that is really powerful and important.”

Rice said HackerOne last year took an inventory of vulnerability disclosure policies at the Global Forbes 2000 list of companies, and found that only six percent of them had published guidelines.

“You cannot run an effective public vulnerability disclosure program or a bug bounty program without having competent security professionals internally,” Rice said. “The problem is, the vast majority of organizations don’t have that.”

Image: Hackerone.
And when you start asking people to find and report gaps in your cybersecurity armor, you’d better be ready for them to do just that, said Jeremiah Grossman, chief security of strategy at anti-malware firm SentinelOne.

“I’ve seen people try to launch these vulnerability disclosure programs and then fail spectacularly because they don’t have the resources to handle the response,” said Grossman, who also serves on the advisory board for Bugcrowd — one of HackerOne’s competitors. “When you’re really mature in security, and not before then, is about the right time for a bug bounty program. If the organization can handle one to five vulnerabilities reported each month and can fix each of those in a few days, then they’re probably ready.”

Rice said one reason he’s so excited about bug bounty programs is that they offer would-be security professionals a way to demonstrate their skills in a safe and controlled environment.

“If you’re a security professional looking to challenge yourself and your skills, there are very few real world opportunities to do that, to test your mettle and improve,” Rice said. “But that real-world experience is so unbelievably critical in this industry, and we need to be creating more opportunities for people to improve that. The more we can do that and share what we learn out of it, the more we can raise the talent and education of security professionals worldwide.”

Hardly a week goes by when I don’t hear from a young or career-changing reader asking for advice about how to carve out a living in cybersecurity. This happened so often that I created an entire category of posts on this topic: How to Break Into Security. I’ll be revisiting that series soon, but for the time being I want to encourage anyone interested in building their skills through legal hacking to consider creating relationships with companies that have already sanctioned — and in many cases financially reward — such activity.

For starters, Bugcrowd has a nice list of bug bounty and disclosure programs from across the Web, broken down according to whether they offer various benefits such as financial reward, swag or public recognition. Hackerone maintains a searchable directory of security contacts and vulnerability reporting policies at various corporations.
Top

Flashing an LSI SAS 9201-16i – correctly

Postby Dan Langille via Dan Langille's Other Diary »

Three weeks ago, I thought I had flashed my new LSI SAS 9201-16i. I had not. When I powered up the system via mfsBSD, I could see the device, but during the boot process, there was no splash screen. I now believe this should always be a signal that you have not correctly flashed the [...]
Top

OSX was caching my ssh passphrases – easy fix

Postby Dan Langille via Dan Langille's Other Diary »

I have used ssh-agent for a long time. I enter my passphrase once, then let ssh-agent handle my ssh sessions. Last night, I noticed I ssh’d to a box and did not enter my passphrase. I got logged in. I had just rebooted my laptop so I was very concerned about this. It look at [...]
Top

metapixel: multiple assertion failures

Postby ago via agostino's blog »

Description:
metapixel is a program for generating photomosaics.

A fuzzing on metapixel-imagesize revealed multiple assertion failures. The latest upstream release was about ten years ago, so I didn’t made any report. The bugs do not reside in any shared object which aren’t provided by the package. If you have a web application which relies on the metapixel-imagesize binary, then you are affected. Since the crashes reside in the command line tool, they may don’t warrant a CVE at all, but some distros and packagers would have the bugs fixed in their repository, so I’m sharing them.

Affected version:
1.0.2
Output/failure:
metapixel-imagesize: rwgif.c:59: void *open_gif_file(const char *, int *, int *): Assertion `data->file !=0′ failed.
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00059-metapixel-assert-open_gif_file-1

##########################################

Affected version:
1.0.2
Output/failure:
metapixel-imagesize: rwgif.c:63: void *open_gif_file(const char *, int *, int *): Assertion `DGifGetRecordType(data->file, &record_type) != 0′ failed.
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00060-metapixel-assert-open_gif_file-2

##########################################

Affected version:
1.0.2
Output/failure:
metapixel-imagesize: rwgif.c:68: void *open_gif_file(const char *, int *, int *): Assertion `DGifGetImageDesc(data->file) != 0′ failed.
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00061-metapixel-assert-open_gif_file-3

##########################################

Affected version:
1.0.2
Output/failure:
metapixel-imagesize: rwgif.c:102: void *open_gif_file(const char *, int *, int *): Assertion `DGifGetExtension(data->file, &ext_code, &ext) != 0′ failed.
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00062-metapixel-assert-open_gif_file-4

##########################################

Affected version:
1.0.2
Output/failure:
metapixel-imagesize: rwgif.c:106: void *open_gif_file(const char *, int *, int *): Assertion `DGifGetExtensionNext(data->file, &ext) != 0′ failed.
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00063-metapixel-assert-open_gif_file-5

Credit:
These bugs were discovered by Agostino Sarubbo of Gentoo.

Timeline:
2016-11-22: bugs discovered
2016-11-22: blog post about the issues

Note:
These bugs were found with American Fuzzy Lop.

Permalink:

metapixel: multiple assertion failures

Top

metapixel: heap-based buffer overflow in open_gif_file (rwgif.c)

Postby ago via agostino's blog »

Description:
metapixel is a program for generating photomosaics.

A fuzzing on metapixel-imagesize revealed an overflow. The latest upstream release was about ten years ago, so I didn’t made any report. The bug does not resides in any shared object which aren’t provided by the package. If you have a web application which relies on the metapixel-imagesize binary, then you are affected. Since the “READ of size 1” it may don’t warrant a CVE at all, but some distros and packagers would have the bug fixed in their repository, so I’m sharing it.

The complete ASan output:

# metapixel-imagesize $FILE
==24883==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eff9 at pc 0x00000050edcf bp 0x7ffce3891f90 sp 0x7ffce3891f88
READ of size 1 at 0x60200000eff9 thread T0
    #0 0x50edce in open_gif_file /tmp/portage/media-gfx/metapixel-1.0.2-r1/work/metapixel-1.0.2/rwimg/rwgif.c:132:60
    #1 0x50a4cd in open_image_reading /tmp/portage/media-gfx/metapixel-1.0.2-r1/work/metapixel-1.0.2/rwimg/readimage.c:88:9
    #2 0x50a18b in main /tmp/portage/media-gfx/metapixel-1.0.2-r1/work/metapixel-1.0.2/imagesize.c:37:14
    #3 0x7fcc5c3a861f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #4 0x41a1d8 in _init (/usr/bin/metapixel-imagesize+0x41a1d8)

0x60200000eff9 is located 3 bytes to the right of 6-byte region [0x60200000eff0,0x60200000eff6)
allocated by thread T0 here:
    #0 0x4d3195 in calloc /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:72
    #1 0x7fcc5d267392 in GifMakeMapObject /tmp/portage/media-libs/giflib-5.1.4/work/giflib-5.1.4/lib/gifalloc.c:55

SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/portage/media-gfx/metapixel-1.0.2-r1/work/metapixel-1.0.2/rwimg/rwgif.c:132:60 in open_gif_file
Shadow bytes around the buggy address:
  0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9df0: fa fa fa fa fa fa fa fa fa fa 00 fa fa fa 06[fa]
  0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==24883==ABORTING
Affected version:
1.0.2

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

Reproducer:
https://github.com/asarubbo/poc/blob/master/00058-metapipxel-heapoverflow-open_gif_file

Timeline:
2016-11-22: bug discovered
2016-11-22: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

metapixel: heap-based buffer overflow in open_gif_file (rwgif.c)

Top

Akamai on the Record KrebsOnSecurity Attack

Postby BrianKrebs via Krebs on Security »

Internet infrastructure giant Akamai last week released a special State of the Internet report. Normally, the quarterly accounting of noteworthy changes in distributed denial-of-service (DDoS) attacks doesn’t delve into attacks on specific customers. But this latest Akamai report makes an exception in describing in great detail the record-sized attack against KrebsOnSecurity.com in September, the largest such assault it has ever mitigated.

“The attacks made international headlines and were also covered in depth by Brian Krebs himself,” Akamai said in its report, explaining one reason for the exception. “The same data we’ve shared here was made available to Krebs for his own reporting and we received permission to name him and his site in this report. Brian Krebs is a security blogger and reporter who does in-depth research and analysis of cybercrime throughout the world, with a recent emphasis on DDoS. His reporting exposed a stressor site called vDOS and the security firm BackConnect Inc., which made him the target of a series of large DDoS attacks starting September 15, 2016.”

A visual depiction of the increasing size and frequency of DDoS attacks against KrebsOnSecurity.com, between 2012 and 2016. Source: Akamai.
Akamai said so-called “booter” or “stresser” DDoS-for-hire services that sell attacks capable of knocking Web sites offline continue to account for a large portion of the attack traffic in mega attacks. According to Akamai, most of the traffic from those mega attacks in Q3 2016 were thanks to Mirai — the now open-source malware family that was used to coordinate the attack on this site in September and a separate assault against infrastructure provider Dyn in October.

Akamai said the attack on Sept. 20 was launched by just 24,000 systems infected with Mirai, mostly hacked Internet of Things (IoT) devices such as digital video recorders and security cameras.

“The first quarter of 2016 marked a high point in the number of attacks peaking at more than 100 Gbps,” Akamai stated in its report. “This trend was matched in Q3 2016, with another 19 mega attacks. It’s interesting that while the overall number of attacks fell by 8% quarter over quarter, the number of large attacks, as well as the size of the biggest attacks, grew significantly.”

As detailed here in several previous posts, KrebsOnSecurity.com was a pro-bono customer of Akamai, beginning in August 2012 with Prolexic before Akamai acquired them. Akamai mentions this as well in explaining its decision to terminate our pro-bono arrangement. KrebsOnSecurity is now behind Google‘s Project Shield, a free program run by Google to help protect journalists and dissidents from online censorship.

“Almost as soon as the site was on the Prolexic network, it was hit by a trio of attacks based on the Dirt Jumper DDoS tookit,” Akamai wrote of this site. “Those attacks marked the start of hundreds of attacks that were mitigated on the routed platform.”

In total, Akamai found, this site received 269 attacks in the little more than four years it was on the Prolexic/Akamai network.

“During that time, there were a dozen mega attacks peaking at over 100 Gbps,” the company wrote. “The first happened in December 2013, the second in February 2014, and the third in August 2015. In 2016, the size of attacks accelerated dramatically, with four mega attacks happening between March and August, while five attacks occurred in September, ranging from 123 to 623 Gbps. An observant reader can probably correlate clumps of attacks to specific stories covered by Krebs. Reporting on the dark side of cybersecurity draws attention from people and organizations who are not afraid of using DDoS attacks to silence their detractors.”

In case any trenchant observant readers wish to attempt that, I’ve published a spreadsheet here (in .CSV format) which lists the date, duration, size and type of attack used in DDoS campaigns against KrebsOnSecurity.com over the past four years. Although 269 attacks over four years works out to an average of just one attack roughly every five days, both the frequency and intensity of these attacks have increased substantially over the past four years as illustrated by the graphic above.

“The magnitude of the attacks seen during the final week were significantly larger than the majority of attacks Akamai sees on a regular basis,” Akamai reports. “In fact, while the attack on September 20 was the largest attack ever mitigated by Akamai, the attack on September 22 would have qualified for the record at any other time, peaking at 555 Gbps.”

Akamai found that the 3rd quarter of 2016 marks a full year with China as the top source country for DDoS attacks, with just under 30 percent of attack traffic in Q3 2016. The company notes that this metric doesn’t count UDP-based attacks – such as amplification and reflection attacks — due to the ease with which the sources of the attacks can be spoofed and could create significant distortion of the data.

“More importantly, the proportion of traffic from China has been reduced by 56%, which had a significant effect on the overall attack count and led to the 8% drop in attacks seen this quarter,” Akamai reported. The U.S., U.K., France, and Brazil round out the remaining top five source countries.”

Top sources of DDoS attacks. Image: Akamai.
A copy of Akamai’s Q3 2016 State of the Internet report is available here.
Top

jasper: stack-based buffer overflow in jpc_tsfb_getbands2 (jpc_tsfb.c)

Postby ago via agostino's blog »

Description:
jasper is an open-source initiative to provide a free software-based reference implementation of the codec specified in the JPEG-2000 Part-1 standard.

A crafted image, through an intensive fuzz on the 1.900.22 version revealed a stack overflow.

The complete ASan output:

# imginfo -f $FILE
warning: trailing garbage in marker segment (9 bytes)
warning: trailing garbage in marker segment (28 bytes)
warning: trailing garbage in marker segment (40 bytes)
warning: ignoring unknown marker segment (0xffee)
type = 0xffee (UNKNOWN); len = 23;1f 32 ff ff ff 00 10 00 3d 4d 00 01 32 ff 00 e4 00 10 00 00 4f warning: trailing garbage in marker segment (14 bytes)
=================================================================
==9166==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7faf2e200c20 at pc 0x7faf320a985a bp 0x7ffd397b9b10 sp 0x7ffd397b9b08
WRITE of size 4 at 0x7faf2e200c20 thread T0
    #0 0x7faf320a9859 in jpc_tsfb_getbands2 /tmp/portage/media-libs/jasper-1.900.22/work/jasper-1.900.22/src/libjasper/jpc/jpc_tsfb.c:227:16
    #1 0x7faf320a9009 in jpc_tsfb_getbands2 /tmp/portage/media-libs/jasper-1.900.22/work/jasper-1.900.22/src/libjasper/jpc/jpc_tsfb.c:223:3
    #2 0x7faf320a8b9f in jpc_tsfb_getbands /tmp/portage/media-libs/jasper-1.900.22/work/jasper-1.900.22/src/libjasper/jpc/jpc_tsfb.c:187:3
    #3 0x7faf3200eaa6 in jpc_dec_tileinit /tmp/portage/media-libs/jasper-1.900.22/work/jasper-1.900.22/src/libjasper/jpc/jpc_dec.c:714:4
    #4 0x7faf3200eaa6 in jpc_dec_process_sod /tmp/portage/media-libs/jasper-1.900.22/work/jasper-1.900.22/src/libjasper/jpc/jpc_dec.c:560
    #5 0x7faf3201c1c3 in jpc_dec_decode /tmp/portage/media-libs/jasper-1.900.22/work/jasper-1.900.22/src/libjasper/jpc/jpc_dec.c:391:10
    #6 0x7faf3201c1c3 in jpc_decode /tmp/portage/media-libs/jasper-1.900.22/work/jasper-1.900.22/src/libjasper/jpc/jpc_dec.c:255
    #7 0x7faf31f7e684 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.22/work/jasper-1.900.22/src/libjasper/base/jas_image.c:406:16
    #8 0x509c9a in main /tmp/portage/media-libs/jasper-1.900.22/work/jasper-1.900.22/src/appl/imginfo.c:203:16
    #9 0x7faf3108761f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #10 0x419988 in _init (/usr/bin/imginfo+0x419988)

Address 0x7faf2e200c20 is located in stack of thread T0 at offset 3104 in frame
    #0 0x7faf3200dbbf in jpc_dec_process_sod /tmp/portage/media-libs/jasper-1.900.22/work/jasper-1.900.22/src/libjasper/jpc/jpc_dec.c:544

  This frame has 1 object(s):
    [32, 3104) 'bnds.i' 0x0ff665c38180: 00 00 00 00[f3]f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3
  0x0ff665c38190: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff665c381a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff665c381b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff665c381c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff665c381d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==9166==ABORTING
Affected version:
1.900.22

Fixed version:
1.900.30

Commit fix:
https://github.com/mdadams/jasper/commit/1abc2e5a401a4bf1d5ca4df91358ce5df111f495

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-9560

Reproducer:
https://github.com/asarubbo/poc/blob/master/00047-jasper-stackoverflow-jpc_tsfb_getbands2

Timeline:
2016-11-09: bug discovered and reported to upstream
2016-11-20: upstream released a patch
2016-11-20: blog post about the issue
2016-11-23: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

jasper: stack-based buffer overflow in jpc_tsfb_getbands2 (jpc_tsfb.c)

Top

imagemagick: null pointer must never be null (tiff.c)

Postby ago via agostino's blog »

Description:
imagemagick is a software suite to create, edit, compose, or convert bitmap images.

A fuzz on an updated version with the undefined behavior sanitizer enabled, revealed a null pointer which is declared to never be null.

The complete UBSan output:

# identify $FILE
coders/tiff.c:655:39: runtime error: null pointer passed as argument 2, which is declared to never be null
MagickCore/string_.h:76:23: note: nonnull attribute specified here
Affected version:
7.0.3.6

Fixed version:
7.0.3.7

Commit fix:
https://github.com/ImageMagick/ImageMagick/commit/b61d35eaccc0a7ddeff8a1c3abfcd0a43ccf210b

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-9559

Reproducer:
https://github.com/asarubbo/poc/blob/master/00049-imagemagick-pointernerverbenull

Timeline:
2016-11-09: bug discovered and reported to upstream
2016-11-09: upstream released a patch
2016-11-15: upstream released 7.0.3.7
2016-11-19: blog post about the issue
2016-11-23: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

imagemagick: null pointer must never be null (tiff.c)

Top

An alternative to git bisect with Gentoo and the live ebuild

Postby ago via agostino's blog »

Git bisect is absolutely powerful, but sometimes is more comfortable use emerge instead of compile the software outside the package manager.

That was my case with media-libs/jasper which I’m picking as example for this ‘howto’

So basically, you are running Gentoo, you can install a live ebuild (9999) and you want to find which commit id fixes an issue. Let’s see step-by-step what to do.

1) Clone the repository to obtain the commit ids and put them in a file

ago@blackgate ~ $ cd /tmp
ago@blackgate /tmp $ git clone https://github.com/mdadams/jasper.git
ago@blackgate /tmp $ cd jasper/
ago@blackgate /tmp/jasper $ git --no-pager log . | grep "commit" | sed "s:commit ::g" > /tmp/commitlist.txt
The file should contain the git commit ids, for example:

883f85876a463019a16b6d38dd9afc022d1f07cf
de4e3953fd3ef9d539c5187b7988e8750b3d67c9
f9ccc661fd1094c8d1c3df38b51295677d268dbf
2) Manually check the file to be sure it does not contain unexpected line, since we grep for the ‘commit’ word.

3) Use a simple script which runs emerge and the command you need to test.

#!/bin/bash
for COMMIT_ID in $( cat /tmp/commitlist.txt )
do
        echo "Testing with the commit id: "${COMMIT_ID}""
        EGIT_COMMIT="${COMMIT_ID}" emerge -q media-libs/jasper
        imginfo -f /tmp/myjpg.jpg
        echo -ne "\n\n\n"
done
With the EGIT_COMMIT variable from the git-* eclass, we can emerge the live ebuild at a specific commit id.
imginfo is in my case the command I need and then I print some blank lines to better separate the output of the commands and understand what is happening.

Now you need to wait and just check what is the output of the specified command.

SOME IMPORTANT NOTES:
– This howto looks to be valid when the project you are building is small; running this script with e.g. libreoffice will take months.
– This howto looks to be valid when you know that the problem is near to the commit master and will take few emerge cycles to found the issue.
– If you know that the problem is fixed e.g. a year ago, you can manually edit the commitlist.txt file and delete some recent ids, to have a specified and minor range of commits.

That’s all.
Top

libdwarf: negation overflow in dwarf_leb.c

Postby ago via agostino's blog »

Description:
libdwarf is a library to consume and produce DWARF debug information.

A fuzz with the Undefined Behavior Sanitizer shows a negation that cannot be represented as long long.

The complete UBSan output:

# dwarfdump $FILE
dwarf_leb.c:306:19: runtime error: negation of -9223372036854775808 cannot be represented in type 'Dwarf_Signed' (aka 'long long'); cast to an unsigned type to negate this value to itself
Affected version:
20161021

Fixed version:
20161124

Commit fix:
https://sourceforge.net/p/libdwarf/code/ci/4f19e1050cd8e9ddf2cb6caa061ff2fec4c9b5f9/#diff-5

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-9558

Reproducer:
https://github.com/asarubbo/poc/blob/master/00050-libdwarf-negate-itself

Timeline:
2016-11-11: bug discovered and reported to upstream
2016-11-11: upstream released a patch
2016-11-19: blog post about the issue
2016-11-23: CVE assigned
2016-11-24: upstream released 20161124

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libdwarf: negation overflow in dwarf_leb.c

Top

jasper: signed integer overflow in jas_image.c

Postby ago via agostino's blog »

Description:
jasper is an open-source initiative to provide a free software-based reference implementation of the codec specified in the JPEG-2000 Part-1 standard.

The undefined behavior sanitizer shows a signed integer overflow in jas_image.c
As you can see, the commit which fixes the issue is not a fix itself for the signed integer overflow, but changed a bit how, in jasper, the things work.

The complete UBSan output:

# imginfo -f $FILE
/tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/base/jas_image.c:162:49: runtime error: signed integer overflow: 8543608947741818625 * 15 cannot be represented in type 'long'
Affected version:
1.900.17

Fixed version:
1.900.25

Commit fix:
https://github.com/mdadams/jasper/commit/d42b2388f7f8e0332c846675133acea151fc557a

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-9557

Reproducer:
https://github.com/asarubbo/poc/blob/master/00020-jasper-signedintoverflow-jas_image_c

Timeline:
2016-10-29: bug discovered and reported to upstream
2016-11-12: upstream released a patch and 1.900.25
2016-11-19: blog post about the issue
2016-11-23: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

jasper: signed integer overflow in jas_image.c

Top

imagemagick: heap-based buffer overflow in IsPixelGray (pixel-accessor.h)

Postby ago via agostino's blog »

Description:
imagemagick is a software suite to create, edit, compose, or convert bitmap images.

A fuzz on an updated version revealed another overflow.

The complete ASan output:

# identify $FILE
=================================================================
==696==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x611000009700 at pc 0x7f300036c9a3 bp 0x7fff6e225970 sp 0x7fff6e225968
READ of size 4 at 0x611000009700 thread T0
    #0 0x7f300036c9a2 in IsPixelGray /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/./MagickCore/pixel-accessor.h:507:30
    #1 0x7f300036c9a2 in IdentifyImageGray /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickCore/attribute.c:677
    #2 0x7f300036f0dd in IdentifyImageType /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickCore/attribute.c:821:7
    #3 0x7f300090c1da in IdentifyImage /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickCore/identify.c:527:8
    #4 0x7f2fff364075 in IdentifyImageCommand /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickWand/identify.c:336:22
    #5 0x7f2fff4afeca in MagickCommandGenesis /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickWand/mogrify.c:183:14
    #6 0x50a339 in MagickMain /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/utilities/magick.c:145:10
    #7 0x50a339 in main /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/utilities/magick.c:176
    #8 0x7f2ffd99c61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #9 0x419d28 in _init (/usr/bin/magick+0x419d28)

0x611000009700 is located 0 bytes to the right of 192-byte region [0x611000009640,0x611000009700)
allocated by thread T0 here:
    #0 0x4d3685 in posix_memalign /tmp/portage/sys-devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:130
    #1 0x7f3000a466b0 in AcquireAlignedMemory /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickCore/memory.c:258:7
    #2 0x7f300043addf in AcquireCacheNexusPixels /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickCore/cache.c:4636:33
    #3 0x7f3000402030 in SetPixelCacheNexusPixels /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickCore/cache.c:4748:14
    #4 0x7f30003e7d2d in GetVirtualPixelsFromNexus /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickCore/cache.c:2629:10
    #5 0x7f3000444e53 in GetCacheViewVirtualPixels /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickCore/cache-view.c:664:10
    #6 0x7f300036b27c in IdentifyImageGray /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickCore/attribute.c:672:7
    #7 0x7f300036f0dd in IdentifyImageType /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickCore/attribute.c:821:7
    #8 0x7f300090c1da in IdentifyImage /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickCore/identify.c:527:8
    #9 0x7f2fff364075 in IdentifyImageCommand /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickWand/identify.c:336:22
    #10 0x7f2fff4afeca in MagickCommandGenesis /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/MagickWand/mogrify.c:183:14
    #11 0x50a339 in MagickMain /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/utilities/magick.c:145:10
    #12 0x50a339 in main /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/utilities/magick.c:176
    #13 0x7f2ffd99c61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289

SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/portage/media-gfx/imagemagick-7.0.3.6/work/ImageMagick-7.0.3-6/./MagickCore/pixel-accessor.h:507:30 in IsPixelGray
Shadow bytes around the buggy address:
  0x0c227fff9290: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c227fff92d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c227fff92e0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c227fff9300: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
  0x0c227fff9310: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c227fff9320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c227fff9330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==696==ABORTING
Affected version:
7.0.3.6

Fixed version:
7.0.3.8

Commit fix:
https://github.com/ImageMagick/ImageMagick/commit/ce98a7acbcfca7f0a178f4b1e7b957e419e0cc99

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-9556

Reproducer:
https://github.com/asarubbo/poc/blob/master/00051-imagemagick-heapoverflow-IsPixelGray

Timeline:
2016-11-16: bug discovered and reported to upstream
2016-11-17: upstream released a patch
2016-11-19: blog post about the issue
2016-11-23: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

imagemagick: heap-based buffer overflow in IsPixelGray (pixel-accessor.h)

Top

Adobe Fined $1M in Multistate Suit Over 2013 Breach; No Jail for Spamhaus Attacker

Postby BrianKrebs via Krebs on Security »

Adobe will pay just $1 million to settle a lawsuit filed by 15 state attorneys general over its huge 2013 data breach that exposed payment records on approximately 38 million people. In other news, the 39-year-old Dutchman responsible for coordinating an epic, weeks-long distributed denial-of-service attack against anti-spam provider Spamhaus in 2013 will avoid any jail time for his crimes thanks to a court ruling in Amsterdam this week.

On Oct. 3, 2013, KrebsOnSecurity broke the story that Adobe had just suffered a breach in which hackers siphoned usernames, passwords and payment card data on 38 million customers. The intruders also made off with digital truckloads of source code for some of Adobe’s most valuable software properties — including Adobe Acrobat and Reader, Photoshop and ColdFusion.

On Monday, Nov. 11, North Carolina Attorney General  Roy Cooper joined his counterparts in 14 other states in announcing a $1 million settlement with Adobe over the 2013 breach. According to Cooper, the hacked Adobe servers contained the personal information of approximately 552,000 residents of the participating 15 states. That works out to about $1.80 per victim across all 15 states.

A posting on anonnews.org that was later deleted.
According to a statement by Massachusetts Attorney General Maura Healey, “an investigation by the states revealed that in September 2013, Adobe received an alert that the hard drive for one of its application servers was nearing capacity. In responding to the alert, Adobe learned that an unauthorized attempt was being made to decrypt customer payment card numbers maintained on the server.”

“Adobe discovered that one or more unauthorized intruder(s) had compromised a public-facing web server and used it to access other servers on Adobe’s network, including areas where Adobe stored consumer data,” the statement from Healey’s office reads. “The intruder(s) ultimately stole consumer data from Adobe’s servers, including encrypted payment card numbers and expiration dates, names, addresses, telephone numbers, e-mail addresses, usernames (Adobe IDs), and passwords associated with the usernames.”

When I think of the Adobe breach I’m reminded of that scene out of the 1982 Spielberg horror classic “Poltergeist,” when Craig T. Nelson as “Steve Freeling” seizes the horrified neighborhood developer Mr. Teague by his coat collars and screams, “You son of a bitch! You moved the cemetery but you left the bodies, didn’t ya?! You left left the bodies and you only moved the headstones!! Why?!?!?! Whyyyyyyeeeiee??!?!?”

A scene from Poltergeist. Image: IMDB.
Likewise, Adobe had various storefronts for its various software products, but it eventually centralized many store operations. The main trouble was the company left copies of their customer records in multiple internal network locations that were no longer as protected as Adobe’s globally centralized storefront.

North Carolina’s Cooper said in a statement on the settlement that businesses and government must do more to protect consumer data. But if this settlement was meant as a deterrent to dissuade other companies from hosting customer payment data on public-facing Web servers, the fine might be more effective if it were more commensurate with the company’s size and the number of customers impacted.

As Digital Trends notes, such a breach under the new General Data Protection Regulation going into effect in 2018, would be quite a bit more costly. “Adobe could face fines of up to four percent of its annual global turnover,” wrote Jonathan Keane for DT. “Last we checked, Adobe’s previous quarterly earnings were $1.4 billion.”

Keane also notes that Adobe had previously settled a similar case in California where it settled for an undisclosed amount and $1.1 million in legal fees.

One interesting nugget tucked in at the end of the statement from the North Carolina AG’s office is this bit: More than 3,700 breaches impacting nearly 10 million North Carolinians have been reported since the state’s data breach notification law took effect in 2005, including 677 breaches reported so far in 2016. According to the United States Census Bureau, there were just over 10 million residents in North Carolina as of July 2015.

That means just about everyone in North Carolina was impacted by at least one data breach over the past 12 years. I’d wager this is true for just about every state in the Union, and probably many times over for some. A handful of lucky states have had single breaches that affected all citizens at once.

In 2012, a phishing attack against an employee of the South Carolina Department of Revenue allowed intruders to make off with Social Security numbers and other personal data on 3.8 million electronic tax filers, as well as 1.9 million of their dependents. Also in that breach, nearly 700,000 businesses, 3.3 million bank accounts and 5,000 expired credit cards were compromised. As of July 2015, South Carolina had fewer than five million residents, according to the Census Bureau.

SVEN OLAF KAMPHUIS — A.K.A. “Prince of Cyberbunker Republic”

In March 2013, a coalition of spammers and spam-friendly hosting firms pooled their resources to launch what would become the largest distributed denial-of-service (DDoS) attack the Internet had ever witnessed. The assault briefly knocked offline the world’s largest anti-spam organization, and caused a great deal of collateral damage to innocent bystanders in the process. Here’s a never-before-seen look at how that attack unfolded, and a rare glimpse into the shadowy cybercrime forces that orchestrated it.

That paragraph above was the lead for a story I published in August 2016, “Inside the Attack that Almost Broke the Internet“. It’s starring member was a colorful Dutchman named Sven Olaf Kamphuis who ran a technology services company called CB3ROB. This CB3ROB in turn provided services for a Dutch company called “Cyberbunker,” so named because the organization was allegedly housed in a five-story NATO bunker and because it had advertised its services as a bulletproof hosting provider.

A snippet from a very long chat log published here detailing the extended DDoS campaigns waged against Spamhaus.
Kamphuis seemed to honestly believe his Cyberbunker was sovereign territory, even signing his emails “Prince of Cyberbunker Republic.” Arrested in Spain in April 2013 in connection with the attack on Spamhaus, Kamphuis was later extradited to The Netherlands to stand trial. He has publicly denied being part of the attacks, but the chat logs with him coordinating the attack with co-conspirators are fairly damning considering he didn’t even use an alias in the discussions and live-posted his campaign of terror to his Facebook account.

Nevertheless, a judge in Amsterdam this week sentenced Kamphuis to a total of 240 days in jail. However, the judge also counted the 55 days Kamphuis spent awaiting extradition from Spain, and suspended the remaining 185-day sentence. No jail time for Kamphuis.

Spamhaus founder Steve Linford said the organization was disappointed in the sentence, and it warned Kamphuis about any thoughts of retaliation.

“We had hoped for a longer jail sentence to send the message that organising and conducting DDoS attacks is a crime not acceptable to law courts or society, however the ease with which Kamphuis was arrested and extradited, and the two months already served in jail will hopefully have delivered the message to him that there is no escape from the law should he attempt any attacks in the future,” Linford wrote in a email. “Since the remainder of the term is a suspended sentence, any actions or threats made to Spamhaus during the term would be filed with the court as a violation of the conditions of the suspended sentence.”

Facebook profile picture of Sven Olaf Kamphuis
The only other person charged in connection with the largest attack the Internet had ever seen at the time was Sean Nolan McDonough, a.k.a. “narko” in the chat logs referenced in the snippet pictured above.

Narko was a juvenile when he was arrested by the U.K.’s National Crime Agency (NCA); when the NCA raided Narko’s home, they found his computer still logged in to crime forums, and they seized £70,000 from his bank account (believed to be payments for DDoS attacks). Narko later pleaded guilty to coordinating the attacks and was sentenced to 240 hours of community service, but because of his age and in return for cooperating with the NCA he avoided a jail term.

This sentence sends the wrong message and misses the mark by a mile. The message we as a society of Internet users continue to send by our unwillingness to punish people for these crimes is, “Hey, if you’re involved in heavily disrupting networks and commerce through botnet attacks, you don’t have to worry because you’ll either never be prosecuted…or if you are the sentence will be community service or nothing.”

Neither of the two 18-year-old Israeli men arrested in September for their role in selling the massively profitable vDOS attack-for-hire service to knock Web sites offline have been indicted by the Israeli, British or American governments. The hammer has yet to fall on those responsible for lobbing the record 620 Gpbs attack on my site, or the individual(s) involved in the attack on Dyn that disrupted service for some of the Web’s top destinations. I’m afraid the wheels of justice still creak forward far too slowly in Internet time for the threat of prosecution to be much of an immediate deterrent against online hooliganism in the here-and-now.
Top

Chinese IoT Firm Siphoned Text Messages, Call Records

Postby BrianKrebs via Krebs on Security »

A Chinese technology firm has been siphoning text messages and call records from cheap Android-based mobile smart phones and secretly sending the data to servers in China, researchers revealed this week. The revelations came the same day the White House and the U.S. Department of Homeland Security issued sweeping guidelines aimed at building security into Internet-connected devices, and just hours before a key congressional panel sought recommendations from industry in regulating basic security standards for so-called “Internet of Things” (IoT) devices.

At the center of the spyware controversy is software made by Shanghai ADUPS Technology, a Chinese firm whose product touts the ability to wirelessly update software installed on mobile and and IoT devices. The ADUPS technology is typically bundled with smart phones made by dozens of global wireless firms including ZTE, BLU and Huawei, and sold at popular consumer destinations like Amazon and BestBuy. Often retailing for between $50 and $100, the sleek and powerful devices sell so cheaply because they also require the user to accept on-screen advertisements.

An About Us page at ADUPS’s Web site explains the company’s foothold in the IoT market.
According to research released this week, the low up-front cost of these smart phones may be subsidized not just by ads but by also by the theft of private information stolen from users. Researchers at Fairfax, Va.-based security firm Kryptowire say the ADUPS software gives the company near-total control over the devices that it runs on, and that they have proof ADUPS has abused that control to siphon personal data from countless consumers.

Kryptowire researchers say they stumbled upon ADUPS’s spyware capabilities by accident after purchasing a $59 BLU R1 HD smart phone from Amazon.com for use during international travel. Prying apart the phone and the ADUPS software, they discovered that all call records and text messages to and from the device were being digitally copied, encrypted and secretly forwarded to a server in Shanghai, China every 72 hours.

They also learned that ADUPS’s product was able to mine user text messages for specific strings of text, as well as install and remove any software from host devices.

“This behavior cannot be detected by mobile anti-virus tools because they assume that software that ships with the device is not malware and that it is white-listed,” Kryptowire wrote in an advisory published Tuesday. “We were able to capture, decrypt, and trace the data on the network as they were sent to multiple server locations that are located in Shanghai, China.”

In a statement posted to its Web site, ADUPS said it collects “model information, device status, application information, bin/xbin information and summary information from phones and messages,” and that it has done so “in response to user demand to screen out junk texts and calls from advertisers.”

ADUPS further claims that the functionality was added in June 2016 to some Blu Product Inc. devices, and that it has since shipped an update through its firmware updating software to disable the spying functionality on Blu phones.

But Azzedine Benameur, director of research at Kryptowire, said ADUPS’s software — deeply embedded alongside the operating system on these mobile devices — gives it full ability to re-enable the spyware capabilities at any time. He says ADUPS’s public response to their research raises more questions than it answers.

“They do not provide how many devices were affected and how the data were used,” Benameur said. “Also, they don’t mention who had access to that data, including third parties and the Chinese government. Also, there might be other [manufacturers] and device models affected that ADUPS does not mention.”

ADUPS claims on its Web site to have worldwide presence with more than 700 million active users, and that its firmware is integrated into “more than 400 leading mobile operators, semiconductor vendors and device manufacturers spanning from wearable and mobile devices to cars and televisions.”

“This is just one random device of theirs that we looked at,” Benameur said. “For a company that claims to provide over-the-air updates for 700 million devices, including cars and millions of IoT devices…this is really scary and unacceptable behavior.”

ADUPS’s offer to business partners, circa January 2015.
ADUPS’s current site promises the company’s partners “big data analytics” and higher profit for partners. Earlier versions of the same page from 2015 and cached at the Internet Archive promise partners a slightly less euphemistic menu of services, from an “app push service,” and “device data mining” to “unique package checking” and “mobile advertising.” Interestingly, this story from January 2015 documents how ADUPS’s software has been used to install unwanted apps on customer mobile devices.

As for the Blu R1 HD phone? Benameur said it would be nice if it came with a disclosure that owners can expect zero privacy or control while using it. Aside from that? “At $59, it’s a steal,” Benameur said. “Minus the spyware, it’s a great phone.”

NEW IOT REGULATIONS?

The ADUPS scandal, first reported by The New York Times, comes as U.S. lawmakers are under increasing pressure to legislate basic software security standards for Internet-connected devices. Many low-cost IoT devices — from consumer routers to security cameras and digital video recorders (DVRs) — ship with little to no security built in. This has left millions of consumer devices ripe for exploitation by malicious hackers who enslave the devices in powerful cyber attacks designed to knock Web sites offline and otherwise disrupt Internet services.

Two of those attacks — an hours-long digital siege in October against Internet infrastructure provider Dyn, and a September attack that crippled KrebsOnSecurity for days — harnessed the computing power and network bandwidth of hundreds of thousands of Internet-based cameras and DVRs that were secured with the same default password and configured to be remotely controllable over the Web. A Chinese manufacturing firm whose electronics featured prominently in many of the IoT devices used in those attacks recently said it was issuing a recall for millions of the vulnerable devices — which were shipped with user credentials that were hard-coded into the devices and that could not be easily changed by users.

Both the attack on Dyn and against this site were referenced on multiple occasions today by lawmakers and witnesses to a U.S. House Energy & Commerce Committee hearing titled “Understanding the Role of Connected Devices in Recent Cyber Attacks.”

Bruce Schneier, a security expert who has long advocated holding software vendors legally liable for producing fundamentally flawed and/or insecure products, said the IoT attacks and this latest scandal with ADUPS are examples of a market failure that is crying out for government regulation.

“In many ways, the Dyn attack was benign,” Schneier said in his written testimony. “Some websites went offline for a while. No one was killed. No property was destroyed. But computers have permeated our lives. The Internet now affects the world in a direct physical manner. The Internet of Things is bringing computerization and connectivity to many tens of millions of devices worldwide. We are connecting cars, drones, medical devices, and home thermostats. What was once benign is now dangerous.”

Schneier encouraged lawmakers to think about commercial software and hardware that gets shipped with junk security as a form of pollution: But instead of pumping liquid toxic waste into thinly-lined man-made cesspools, many makers of low-end electronics are churning out default-insecure products that will likely remain in operation — and therefore a public nuisance — for many years to come.

“We’re asking consumers to shore up lousy products,” Schneier told the committee. “It shouldn’t be that there are default passwords. These devices are low profit margin, they’re made offshore. And the buyer and seller don’t care. I might own this DVR, you might own it. You don’t know if it’s secure or not. You can’t test it. And you fundamentally don’t care. You bought it for the features and the price.”

Rep. Anna Eshoo (D-Calif.) called attention to a bill she’s offered — the Promoting Good Cyber Hygiene Act of 2015 — that calls on government regulators to develop best practices aimed at boosting public and private sector network security. As noted above, the White House and the Department of Homeland Security both did just that on Tuesday, each issuing guidelines on cybersecurity for IoT devices.

“We need a good housekeeping seal of approval on this, and my bill called for NIST [the National Institute of Standards and Technology] to set the standards — not Congress — because we really don’t know anything about that, and when we miss the mark we miss it by a wide mile,” Eshoo said.

Indeed, some experts have advocated creating a sort of government-approved Underwriters Laboratories for cybersecurity that would perhaps imprint its seal of approval on certified IoT devices. But Schneier said most consumers are unlikely to be moved by “a sticker that says this device costs $20 more and is 30 percent less likely to annoy people you don’t know.”

Instead, he suggested Congress should create a new federal agency to regulate basic secure design standards for IoT devices. “A U.S.-only regulatory system will affect the products in the rest of the world because this is software,” Schneier said. “Companies will make one software and sell it everywhere. It makes no sense for anyone to come up with two versions of their software.”

Bruce Schneier, left, and Kevin Fu.
Rep. Eshoo called the prospect of creating new bureaucracy in a Republican controlled Congress and White House an idea that was “dead in the water.”

“We have a continuing new, new majority and I don’t think they want to create a new agency,” Eshoo said. “They don’t like stuff like that. New agencies, new regulations, we’re dead in the water. But we can’t leave this issue dead in the water. Our country deserves better.”

If this Congress or the next is reluctant to mandate basic cybersecurity standards for IoT devices, they may soon find themselves forced to legislate in a hurry when people start dying because of IoT insecurity, Schneier said.

“The government is getting involved here regardless,” he said. “The risks are too great and stakes are too high, and nothing motivates government into action [more] than security and fear. In 2001, we had another small-government, no-regulation administration produce a new federal agency 44 days after the terrorist attacks. If something similar happens with the Internet of Things, we’re going to have a similar response. I see the choice here not between government involvement and no government involvement, but between smart government and stupid government. This is the world of dangerous things, and we regulate dangerous things.”

Emphasizing that point, Kevin Fu, chief executive at healthcare security provider Virta Laboratories, told the panel that healthcare and medical device community dodged a bullet on the Dyn attack.

“Hospitals survived not by design, but by luck. The adversary did not target healthcare. This time,” Fu said in his written testimony (PDF). “Dyn represents a single point of failure for resolving Internet names, but hospitals have other kinds of single points of failure. For instance, heating and ventilation now resembles IoT with unpatched computers controlling negative pressure in units with highly infectious diseases.”

Such attacks, he said, have very quickly moved from the theoretical to real life. Earlier this month, a denial-of-service attack like the one that knocked my site and Dyn offline was reportedly used to shut off environmental controls at two apartment buildings in Finland, temporarily leaving residents there without heat or hot water for several days. Also this month, a hospital in the United Kingdom was forced to cancel surgeries and divert trauma patients to nearby hospitals after a cyberattack shut down its internal systems.

Fu urged Congress to study the feasibility of standing up an independent, national embedded cybersecurity testing facility modeled after the automotive crash testing conducted by the National Transportation Safety Board (NTSB). Such a center, he posited, could serve as a security test-bed for everything from consumer IoT devices to far more sensitive medical equipment and embedded health and safety devices, more of which are being connected to the Internet each day.

“The Mayo Clinic reportedly spends roughly $300K per medical device to perform security assessment, and they have thousands of models of devices,” Fu explained. “It makes little economic sense to have individual hospitals testing the security of devices that ought to remain secure for all 6,000 hospitals in the USA. Cybersecurity ought to be a public good much like automobile safety. Imagine if every car dealer were individually responsible for crash testing automobiles: costs would skyrocket and the public would have little confidence. A facility for embedded cybersecurity at the scale of a hospital could provide testing to both government and industry, while allowing students to conduct innovative research during surplus time.”

Fu also suggested that the government could do a much better job working with industry partners to encourage more people to pursue careers in cybersecurity.

“There are tens of thousands of unfilled cybersecurity jobs in the USA,” Fu said. “Existing approaches aren’t insufficient to train a large enough work force to counter growing cybersecurity threats against IoT devices, our economy, and infrastructure.”

Whether or not Congress tries to improve IoT security, miscreants who leverage poor IoT security for criminal purposes will continue their search for additional systems that can be rented out in denial-of-service attacks or used in high-stakes digital shakedowns for money, said Dale Drew, chief security officer at Level 3 Communications.

“Bad actors are increasingly attracted to IoT devices since they can use those devices without being detected for long periods of time, they know most devices will not be monitored or updated, and they know there are no endpoint protection capabilities on IoT devices that can detect and remove the threats,” Drew said.  “Network operators, device manufacturers and users will need to remain vigilant to the security risks these devices present.”

Update, Nov. 20, 2:47 p.m. ET: ZTE issued the following statement. ““We confirm that no ZTE devices in the U.S. have ever had the Adups software cited in recent news reports installed on them, and will not.  ZTE always makes security and privacy a top priority for our customers. We will continue to ensure customer privacy and information remain protected.” ZTE has not responded to questions about whether ZTE devices outside the United States might have been affected.
Top

slocum

Postby Dan Langille via Dan Langille's Other Diary »

This server recently moved to a rack-mount chassis. On an interim basis, it contains an LSI SAS 9101-16i. For future reference, this is the slocum server, which I use for various jails and services. The filesystems, well, some of them: And dmesg:
Top

jasper: multiple Assertion failure

Postby ago via agostino's blog »

Description:
jasper is an open-source initiative to provide a free software-based reference implementation of the codec specified in the JPEG-2000 Part-1 standard.

A fuzzing revealed multiple assertion failures.
Since the jasper’s maintainer releases frequently, the fuzzing was done across multiple versions. The “affected version” tag means that it was tested and discovered on that version, so previously versions may be affected too.
The latest failures are unfixed. I will update the post when upstream will work on them.

Affected version:
1.900.12
Output/failure:
imginfo: /tmp/portage/media-libs/jasper-1.900.12/work/jasper-1.900.12/src/libjasper/base/jas_seq.c:90: jas_matrix<= yend' failed.
Commit fix:
https://github.com/mdadams/jasper/commit/d91198abd00fc435a397fe6bad906a4c1748e9cf
Fixed version:
1.900.13
Testcase:
https://github.com/asarubbo/poc/blob/master/00003-jasper-assert-jas_matrix_t
CVE:
CVE-2016-9387

######################################################

Affected version:
1.900.13
Output/failure:
/tmp/portage/media-libs/jasper-1.900.13/work/jasper-1.900.13/src/libjasper/ras/ras_dec.c:330: int ras_getcmap(jas_stream_t *, ras_hdr_t *, ras_cmap_t *): Assertion `numcolors <= 256' failed.
Commit fix:
https://github.com/mdadams/jasper/commit/411a4068f8c464e883358bf403a3e25158863823
Fixed version:
1.900.14
Testcase:
https://github.com/asarubbo/poc/blob/master/00005-jasper-assert-ras_getcmap
CVE:
CVE-2016-9388

######################################################

Affected version:
1.900.13
Output/failure:
imginfo: /tmp/portage/media-libs/jasper-1.900.13/work/jasper-1.900.13/src/libjasper/jpc/jpc_mct.c:146: void jpc_irct(jas_matrix_t *, jas_matrix_t *, jas_matrix_t *): Assertion `((c1)->numrows_) == numrows && ((c1)->numcols_) == numcols && ((c2)->numrows_) == numrows && ((c2)->numcols_) == numcols’ failed.
Commit fix:
https://github.com/mdadams/jasper/commit/dee11ec440d7908d1daf69f40a3324b27cf213ba
Fixed version:
1.900.14
Testcase:
https://github.com/asarubbo/poc/blob/master/00006-jasper-assert-jpc_irct
CVE:
CVE-2016-9389

######################################################

Affected version:
1.900.13
Output/failure:
type = 0xff76 (UNKNOWN); len = 20;10 40 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 imginfo: /tmp/portage/media-libs/jasper-1.900.13/work/jasper-1.900.13/src/libjasper/jpc/jpc_mct.c:233: void jpc_iict(jas_matrix_t *, jas_matrix_t *, jas_matrix_t *): Assertion `((c1)->numcols_) == numcols && ((c2)->numcols_) == numcols’ failed.
Commit fix:
https://github.com/mdadams/jasper/commit/dee11ec440d7908d1daf69f40a3324b27cf213ba
Fixed version:
1.900.14
Testcase:
https://github.com/asarubbo/poc/blob/master/00008-jasper-assert-jpc_iict
CVE:
CVE-2016-9389

######################################################

Affected version:
1.900.13
Output/failure:
imginfo: /tmp/portage/media-libs/jasper-1.900.13/work/jasper-1.900.13/src/libjasper/base/jas_seq.c:90: jas_matrix_t *jas_seq2d_create(int, int, int, int): Assertion `xstart <= xend && ystart <= yend' failed.
Commit fix:
https://github.com/mdadams/jasper/commit/ba2b9d000660313af7b692542afbd374c5685865
Fixed version:
1.900.14
Testcase:
https://github.com/asarubbo/poc/blob/master/00007-jasper-assert-jas_matrix_t
CVE:
CVE-2016-9390

######################################################

Affected version:
1.900.13
Output/failure:
type = 0xff05 (UNKNOWN); len = 20;01 40 40 00 f0 00 00 00 00 00 00 00 00 00 00 00 00 00 imginfo: /tmp/portage/media-libs/jasper-1.900.13/work/jasper-1.900.13/src/libjasper/jpc/jpc_bs.c:197: long jpc_bitstream_getbits(jpc_bitstream_t *, int): Assertion `n >= 0 && n < 32' failed.
Commit fix:
https://github.com/mdadams/jasper/commit/1e84674d95353c64e5c4c0e7232ae86fd6ea813b
Fixed version:
1.900.14
Testcase:
https://github.com/asarubbo/poc/blob/master/00014-jasper-assert-jpc_bitstream_getbits
CVE:
CVE-2016-9391

######################################################

Affected version:
1.900.13
Output/failure:
imginfo: /tmp/portage/media-libs/jasper-1.900.13/work/jasper-1.900.13/src/libjasper/jpc/jpc_dec.c:1637: void calcstepsizes(uint_fast16_t, int, uint_fast16_t *): Assertion `!((expn + (numrlvls – 1) – (numrlvls – 1 – ((bandno > 0) ? ((bandno + 2) / 3) : (0)))) & (~0x1f))’ failed.
Commit fix:
https://github.com/mdadams/jasper/commit/f7038068550fba0e41e1d0c355787f1dcd5bf330
Fixed version:
1.900.17
Testcase:
https://github.com/asarubbo/poc/blob/master/00012-jasper-assert-calcstepsizes
CVE:
CVE-2016-9392

######################################################

Affected version:
1.900.13
Output/failure:
type = 0xff41 (UNKNOWN); len = 20;02 40 40 00 00 00 00 ee ff 00 00 00 00 24 00 00 00 00 imginfo: /tmp/portage/media-libs/jasper-1.900.13/work/jasper-1.900.13/src/libjasper/jpc/jpc_t2cod.c:297: int jpc_pi_nextrpcl(jpc_pi_t *): Assertion `pi->prcno pirlvl->numprcs’ failed.
Commit fix:
https://github.com/mdadams/jasper/commit/f7038068550fba0e41e1d0c355787f1dcd5bf330
Fixed version:
1.900.17
Testcase:
https://github.com/asarubbo/poc/blob/master/00013-jasper-assert-jpc_pi_nextrpcl
CVE:
CVE-2016-9393

######################################################

Affected version:
1.900.15
Output/failure:
imginfo: /tmp/portage/media-libs/jasper-1.900.15/work/jasper-1.900.15/src/libjasper/base/jas_seq.c:90: jas_matrix_t *jas_seq2d_create(int, int, int, int): Assertion `xstart <= xend && ystart <= yend' failed.
Commit fix:
https://github.com/mdadams/jasper/commit/f7038068550fba0e41e1d0c355787f1dcd5bf330
Fixed version:
1.900.17
Testcase:
https://github.com/asarubbo/poc/blob/master/00016-jasper-assert-jas_matrix_t
CVE:
CVE-2016-9394

######################################################

Affected version:
1.900.22
Output/failure:
warning: trailing garbage in marker segment (9 bytes)
warning: trailing garbage in marker segment (40 bytes)
warning: ignoring unknown marker segment (0xffee)
type = 0xffee (UNKNOWN); len = 23;1f 32 ff ff ff 00 10 00 3d 4d 00 01 32 ff 00 e4 00 10 00 00 4f warning: trailing garbage in marker segment (34 bytes)
imginfo: /tmp/portage/media-libs/jasper-1.900.22/work/jasper-1.900.22/src/libjasper/base/jas_seq.c:90: jas_matrix_t *jas_seq2d_create(int, int, int, int): Assertion `xstart <= xend && ystart <= yend' failed.
Commit fix:
https://github.com/mdadams/jasper/commit/d42b2388f7f8e0332c846675133acea151fc557a
Fixed version:
1.900.25
Testcase:
https://github.com/asarubbo/poc/blob/master/00043-jasper-assert-jas_matrix_t
CVE:
CVE-2016-9395

######################################################

Affected version:
1.900.13
Output/failure:
/tmp/portage/media-libs/jasper-1.900.13/work/jasper-1.900.13/src/libjasper/jpc/jpc_t1cod.c:144: int JPC_NOMINALGAIN(int, int, int, int): Assertion `qmfbid == 0x01′ failed.
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00004-jasper-assert-JPC_NOMINALGAIN
CVE:
CVE-2016-9396

######################################################

Affected version:
1.900.13
Output/failure:
type = 0xff76 (UNKNOWN); len = 20;00 40 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 imginfo: /tmp/portage/media-libs/jasper-1.900.13/work/jasper-1.900.13/src/libjasper/jpc/jpc_dec.c:1817: void jpc_dequantize(jas_matrix_t *, jpc_fix_t): Assertion `absstepsize >= 0′ failed.
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00010-jasper-assert-jpc_dequantize
CVE:
CVE-2016-9397

######################################################

Affected version:
1.900.17
Output/failure:
imginfo: /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_math.c:94: int jpc_floorlog2(int): Assertion `x > 0′ failed.
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00023-jasper-assert-jpc_floorlog2
CVE:
CVE-2016-9398

######################################################

Affected version:
1.900.22
Output/failure:
warning: trailing garbage in marker segment (9 bytes)
warning: trailing garbage in marker segment (28 bytes)
warning: trailing garbage in marker segment (40 bytes)
warning: ignoring unknown marker segment (0xffee)
type = 0xffee (UNKNOWN); len = 23;1f 32 ff ff ff 00 10 00 3d 4d 00 01 32 40 e4 e4 00 10 00 00 4f warning: trailing garbage in marker segment (12 bytes)
imginfo: /tmp/portage/media-libs/jasper-1.900.22/work/jasper-1.900.22/src/libjasper/jpc/jpc_dec.c:1650: void calcstepsizes(uint_fast16_t, int, uint_fast16_t *): Assertion `!((expn + (numrlvls – 1) – (numrlvls – 1 – ((bandno > 0) ? ((bandno + 2) / 3) : (0)))) & (~0x1f))’ failed.
Commit fix:
N/A
Fixed version:
N/A
Testcase:
https://github.com/asarubbo/poc/blob/master/00044-jasper-assert-calcstepsizes
CVE:
CVE-2016-9399

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

Timeline:
2016-10-23: start to report to upstream the issues
2016-11-16: blog post about the issue
2016-11-17: CVE assigned

Note:
These bugs were found with American Fuzzy Lop.

Permalink:

jasper: multiple Assertion failure

Top

This week in vc4 (2016-11-14): Multithreaded fragment shaders

Postby Eric Anholt via anholt's lj »

I dropped HDMI audio last week because Jonas Pfeil showed up with a pair of branches to do multithreaded fragment shaders.

Some context for multithreaded fragment shaders: Texture lookups are really slow.  I think we eyeballed them as having a latency of around 20 QPU instructions.  We can hide latency sometimes if there's some unrelated math to be done after the texture coordinate calculation but before using the texture sample.  However, in most cases, you need the texture sample results right away for the next bit of work.

To allow programs to hide that latency, there's a cooperative hyperthreading mode that a fragment shader can opt into.  The shader stays in the bottom half of register space, and before it collects the results of a texture fetch, it issues a thread switch signal, which the hardware will use to run a second fragment shader thread until that one issues its own thread switch.  For the second thread, the top bit of the register addresses gets flipped, so the two threads' states don't overlap (except for the accumulators and the flags, which the shaders have to save and restore).

I had delayed working on this because the full solution was going to be really tricky: queue up as many lookups as we can, then thread switch, then collect all those results before switching again, all while respecting the FIFO sizes.  However, Jonas's huge contribution here was in figuring out that you don't need to be perfect, you can get huge gains by thread switching between each texture lookup and reading its results.

The upshot was a 0-20% performance improvement on glmark2 and a performance hit to only one testcase.  With this we're down to 3 subtests that we're slower on than the closed source driver.  Jonas's kernel patch is out on the list, and I rewrote the Mesa series to expose threading to the register allocator and landed all but the enabling patch (which has to wait on the kernel side getting merged).  Hopefully I'll finish merging it in a week.

In the process of writing multithreading, Jonas noticed that we were scheduling our TLB_Z writes early in the program, which can cut into fragment shader parallelism between the QPUs (of which we have 12) because a TLB_Z write locks the scoreboard for that 2x2 pixel quad.  I merged a patch to Mesa that pushes the TLB_Z down to the bottom, at the cost of a single extra QPU instruction.  Some day we should flip QPU scheduling around so that we pair that TLB_Z up better, and fill our delay slots in thread switches and branching as well.

I also tracked down a major performance issue in Raspbian's desktop using the open driver.  I asked them to use xcompmgr a while back, because readback from the front buffer using the GPU is really slow (The texture unit can't read from raster textures, so we have to reformat them to be readable), and made window dragging unbearable.  However, xcompmgr doesn't unredirect fullscreen windows, so full screen GL apps emit copies (with reformatting!) instead of pageflipping.

It looks like the best choice for Raspbian is going to be using compton, an xcompmgr fork that does pageflipping (you get tear free screen updates!) and unredirection of full screen windows (you get pageflipping directly from GL apps).  I've also opened a bug report on compton with a description of how they could improve their GL drawing for a tiled renderer like the Pi, which could improve its performance for windowed updates significantly.

Simon ran into some trouble with compton, so he hasn't flipped the default yet, but I would encourage anyone running a Raspberry Pi desktop to give it a shot -- the improvement should be massive.

Other things last week: More VCHIQ patch review, merging more to the -next branches for 4.10 (Martin Sperl's thermal driver, at last!), and a shadow texturing bugfix.
Top

Russian ‘Dukes’ of Hackers Pounce on Trump Win

Postby BrianKrebs via Krebs on Security »

Less than six hours after Donald Trump became the presumptive president-elect of the United States, a Russian hacker gang perhaps best known for breaking into computer networks at the Democratic National Committee launched a volley of targeted phishing campaigns against American political think-tanks and non-government organizations (NGOs).

One of the phishing emails in the latest political espionage attack launched by The Dukes. Source: Volexity.
That’s according to a new report from Washington, D.C.-based cyber incident response firm Volexity. The firm’s researchers say they’ve been closely monitoring the activities of an well-established Russian malware development gang known variously as Cozy Bear, APT29, and The Dukes.

Hacking attacks launched by The Dukes were thought to be connected to intrusions at the Democratic National Committee (DNC), as well as cyber break-ins at multiple high-profile United States Government organizations, Volexity reports in a blog post published Thursday morning.

Last month, the Obama administration publicly acknowledged for the first time that it believed that the Russian government was responsible for stealing and disclosing emails from the DNC and a range of other institutions and prominent individuals, most recently Hillary Clinton’s campaign chairman, John D. Podesta. The emails were posted on WikiLeaks and other sites.

Volexity CEO Steven Adair said The Dukes have launched at least five sorties of email-based malware phishing attacks since Trump’s acceptance speech, and that the malware campaigns are ongoing.

“Two of the attacks purported to be messages forwarded on from the Clinton Foundation giving insight and perhaps a postmortem analysis into the elections,” Adair wrote.”Two of the other attacks purported to be eFax links or documents pertaining to the election’s outcome being revised or rigged. The last attack claimed to be a link to a PDF download on “Why American Elections Are Flawed.

According to Volexity, in July 2015 the Dukes started heavily targeting think tanks and NGOs.

“This represented a fairly significant shift in the group’s previous operations and one that continued in the lead up to and immediately after the 2016 United States Presidential election,” Adair wrote.

Prior to the election, The Dukes were active on August 10, 2016 and on August 25, 2016, launching several waves of highly targeted spear phishing attacks against several U.S.-based think tanks and NGOs.

“These spear phishing messages were spoofed and made to appear to have been sent from real individuals at well-known think tanks in the United States and Europe,” Adair wrote. “These August waves of attacks purported to be from individuals at Transparency International, the Center for a New American Security (CNAS),  the International Institute for Strategic Studies (IISS), Eurasia Group, and the Council on Foreign Relations (CFR).”

Adair said the more typical attacks from The Dukes come in the form of slightly less-targeted email blasts — often to just a few dozen recipients at a time — that include booby-trapped Microsoft Office documents.

When launched, the tainted Excel or Word document opens an actual file with real content, but it also prompts the target to enable “macros” — a powerful functionality built into Office documents that hackers can use to automatically download and run malicious code on a Windows system.

The Dukes prefer to launch the attacks using hacked servers and email inboxes belonging to unsuspecting, trusted workers at NGOs and U.S. government systems, Adair explained. Most often, he said, the intruders will repurpose a legitimate document found in one of these hacked inboxes and inject a sophisticated backdoor “trojan horse program.”

If the phishing target opens the document and has macros enabled in Microsoft Office — or allows macros to be run after the decoy document is shown — a malicious script embedded in the macro installs on the target’s system a powerful foothold for the attacker.

Adair said The Dukes have a well-earned reputation for coding and constantly improving their own custom backdoor trojans, but that they’re not known for using so-called “zero day” threats — previously unknown security weaknesses in software and hardware that knowledgeable attackers can use to remotely compromise a target’s computer just by loading a Web page or opening a document.

“In some ways, these guys seem kind of low-budget, but their macros are well-obfuscated and will sail right through just about any [antivirus] tool, appliance or cloud service,” Adair said in an interview. 

The Dukes also take great care not to phish security personnel at targeted organizations. For example, if the phishing target has macros enabled in Microsoft Office or allows them to be run after the decoy document is shown, a malicious script embedded in the macro executes a busy little program that scours the target’s computer for signs that it is running on an network administrator’s machine.

If the malicious script detects the user is “admin” or “administrator,” the infection goes no further and the malware shuts down. Likewise, it checks many other signs that it might be running in a “sandbox” environment — a test lab often used by security and malware researchers.

Adair said his although his research team doesn’t have specific insight into to how successful these latest espionage attacks may have been, The Dukes are an effective information- and resource gathering machine.

“My opinion is that if this group got access to a zero-day and it’s something they can embed in a document, they could devastate anyone they target,” Adair said. “This is a well-funded and in some respects professional organization. What they’re doing takes time and effort, and for eight plus years now they’ve been in continuous development of new backdoors. They’re continually targeting different verticals — universities, NGOs and governments — and they learn from others, retool and modify their attacks constantly.”

As The New York Times reported last month, “President Obama is weighing a ‘proportional’ response to Russia’s efforts to interfere with this fall’s election campaign through hacking.

Thursday morning, security vendor Kaspersky Lab warned that a massive cyberattack hit five of Russia’s largest banks. Kaspersky said in a statement that the distributed denial of service attacks (DDoS) began Tuesday at 1830 IST and targeted “the websites of at least five well-known financial institutions in the top 10” in Russia.

It remains unclear who launched the bank cyberattacks, which are reportedly ongoing. Kaspersky said the attack on Russia’s banking system is apparently being launched by a network of more than 24,000 hacked Internet of Things (IoT) devices, and that more than half of the hacked things were in the United States, India, Taiwan and Israel.

Further reading on the storied hacking history of The Dukes:

F-Secure calls them CozyDuke (PDF).  FireEye‘s take (PDF). Crowdstrike on Cozy Bear.
Top

Patch Tuesday, 2016 U.S. Election Edition

Postby BrianKrebs via Krebs on Security »

Let’s get this out of the way up front: Having “2016 election” in the headline above is probably the only reason anyone might read this story today. It remains unclear whether Republicans and Democrats can patch things up after a bruising and divisive election, but thanks to a special Election Day Patch Tuesday hundreds of millions of Adobe and Microsoft users have some more immediate patching to do.

As the eyes of the world stayed glued to screens following the U.S. presidential election through the night, Microsoft and Adobe were busy churning out a large number of new security updates for Windows, MS Office, Flash Player and other software. If you use Flash Player or Microsoft products, please take a deep breath and read on.



Regularly scheduled on the second Tuesday of each month, this month’s “Patch Tuesday” fell squarely on Election Day in the United States and included 14 patch bundles. Those patches fixed a total of 68 unique security flaws in Windows and related software.

Six of the 14 patches carry Microsoft’s most’s-dire “critical” label, meaning they fix bugs that malware or miscreants could use to remotely compromise vulnerable PCs without any help from users apart from maybe visiting a hacked or malicious Web site.

Microsoft says two of the software flaws addressed this week are already being exploited in active attacks. It also warned that three of the software vulnerabilities were publicly detailed prior to the release of these fixes – potentially giving attackers a head start in figuring out how to exploit the bugs.

MS16-129 is our usual dogs breakfast of remote code execution vulnerabilities in the Microsoft Edge browser, impacting both HTML rendering and scripting,” said Bobby Kuzma, systems engineer at Core Security. “MS16-130 contains  a privilege escalation in the onscreen keyboard function from Vista forward. That’s great news for anyone running touchscreen kiosks that are supposedly locked down.”

As part of a new Microsoft policy that took effect last month, home and business Windows users will no longer be able to pick and choose which updates to install and which to leave for another time. Consumers on Windows 7 Service Pack 1 and Windows 8.1 will henceforth receive what Redmond is calling a “Monthly Rollup,” which addresses both security issues and reliability issues in a single update. The “Security-only updates” option — intended for enterprises and not available via Windows Update —  will only include new security patches that are released for that month. What this means is that if any part of the patch bundle breaks, the only option is to remove the entire bundle (instead of the offending patch, as was previously possible). 

It’s important to note that several update types won’t be included in a rollup, including those released for Adobe Flash Player on Tuesday. For the second time this month, Adobe issued a critical update for its ubiquitous Flash Player browser plugin. The newest Flash version — v.  23.0.0.207 and available here for both Windows and Mac computers — plugs at least nine more flaws in Flash. To see if you have Flash installed and if so what version is running, check this link.

Google users may need to restart the browser to install or automatically download the latest version. When in doubt, click the vertical three dot icon to the right of the URL bar, select “Help,” then “About Chrome”: If there is an update available, Chrome should install it then.

Somehow KrebsonSecurity neglected to mention the other critical update Adobe pushed for Flash on Oct. 26, 2016 (my bad folks, sorry). It’s really hard to keep up with Flash updates sometimes. That’s part of the reason I’ll continue to encourage readers to disable or remove Adobe Flash unless until it is needed for something specific. Fewer sites now require it, and leaving this buggy, powerful program enabled all the time is just asking for security trouble. Check out the advice at A Month Without Adobe Flash Player for tips on how to hobble or do without Flash entirely.

Indeed, Google reportedly is planning to phase out full support for Flash on its Chrome browser by the end of 2016. And Mozilla is now blocking certain Flash content deemed “not essential to the the user experience.” Specifically, as stated by Mozilla’s Benjamin Smedberg, Mozilla Firefox is blocking specific Flash content that is invisible to users.

“This is expected to reduce Flash crashes and hangs by up to 10%. To minimize website compatibility problems, the changes are initially limited to a short, curated list of Flash content that can be replaced with HTML,” Smedberg wrote back in June. “We intend to add to this list over time.”

For more on this week’s patches, check out coverage from security firms Qualys and Shavlik. And, as always, if you experience any issues downloading or installing any of these updates, please leave a note about it in the comments below.
Top

libming: listmp3: left shift in listmp3.c

Postby ago via agostino's blog »

Description:
libming is a Flash (SWF) output library. It can be used from PHP, Perl, Ruby, Python, C, C++, Java, and probably more on the way..

A fuzzing revealed a left shift in listmp3. The bug does not reside in any shared object but if you have a web application that calls directly the listmp3 binary to parse untrusted mp3, then you are affected.

The complete UBSan output:

# listmp3 $FILE
listmp3.c:94:23: runtime error: left shift of negative value -1
listmp3.c:95:23: runtime error: left shift of negative value -1
Affected version:
0.4.7

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-9266

Reproducer:
https://github.com/asarubbo/poc/blob/master/00046-libming-leftshift-listmp3_c

Timeline:
2016-08-13: bug discovered
2016-10-20: bug reported to upstream
2016-11-09: blog post about the issue
2016-11-10: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libming: listmp3: left shift in listmp3.c

Top

libming: listmp3: divide-by-zero in printMP3Headers (listmp3.c)

Postby ago via agostino's blog »

Description:
libming is a Flash (SWF) output library. It can be used from PHP, Perl, Ruby, Python, C, C++, Java, and probably more on the way..

A fuzzing revealed a divide by zero in listmp3. The bug does not reside in any shared object but if you have a web application that calls directly the listmp3 binary to parse untrusted mp3, then you are affected.

The complete ASan output:

# listmp3 $FILE
ASAN:DEADLYSIGNAL
=================================================================
==29561==ERROR: AddressSanitizer: FPE on unknown address 0x0000004f19e8 (pc 0x0000004f19e8 bp 0x000000000000 sp 0x7ffdf0ab6340 T0)
    #0 0x4f19e7 in printMP3Headers /var/tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/listmp3.c:172:54
    #1 0x4f1bee in main /var/tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/listmp3.c:191:3
    #2 0x7f49407a361f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #3 0x418ae8 in getenv (/usr/bin/listmp3+0x418ae8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE /var/tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/listmp3.c:172:54 in printMP3Headers
==29561==ABORTING
Affected version:
0.4.7

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-9265

Reproducer:
https://github.com/asarubbo/poc/blob/master/00045-libming-fpe-printMP3Headers

Timeline:
2016-08-13: bug discovered
2016-10-20: bug reported to upstream
2016-11-09: blog post about the issue
2016-11-10: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libming: listmp3: divide-by-zero in printMP3Headers (listmp3.c)

Top

libtiff: memory allocation failure in _TIFFCheckRealloc (tif_aux.c)

Postby ago via agostino's blog »

Description:
libtiff is a software that provides support for the Tag Image File Format (TIFF).

During the fuzz of imagemagick, I noticed a memory allocation failure in libtiff. The issue was first reported to the imagemagick’s developers which confirmed that the issue resides in libtiff instead of imagemagick.

The complete ASan output:

# identify $FILE
==26726==ERROR: AddressSanitizer failed to allocate 0x4195c4000 (17605345280) bytes of LargeMmapAllocator (error code: 12)
==26726==Process memory map follows:
        0x000000400000-0x000000520000   /usr/bin/magick
        0x000000720000-0x000000721000   /usr/bin/magick
        0x000000721000-0x000000724000   /usr/bin/magick
        0x000000724000-0x000001397000
        0x00007fff7000-0x00008fff7000
        0x00008fff7000-0x02008fff7000
        0x02008fff7000-0x10007fff8000
        0x600000000000-0x602000000000                                                                                                                                                                                                                                          
        0x602000000000-0x602000010000                                                                                                                                                                                                                                          
        0x602000010000-0x603000000000                                                                                                                                                                                                                                          
        0x603000000000-0x603000010000                                                                                                                                                                                                                                          
        0x603000010000-0x604000000000                                                                                                                                                                                                                                          
        0x604000000000-0x604000020000                                                                                                                                                                                                                                          
        0x604000020000-0x606000000000                                                                                                                                                                                                                                          
        0x606000000000-0x606000020000                                                                                                                                                                                                                                          
        0x606000020000-0x607000000000                                                                                                                                                                                                                                          
        0x607000000000-0x607000010000                                                                                                                                                                                                                                          
        0x607000010000-0x608000000000                                                                                                                                                                                                                                          
        0x608000000000-0x608000010000                                                                                                                                                                                                                                          
        0x608000010000-0x60a000000000                                                                                                                                                                                                                                          
        0x60a000000000-0x60a000020000                                                                                                                                                                                                                                          
        0x60a000020000-0x60b000000000                                                                                                                                                                                                                                          
        0x60b000000000-0x60b000010000                                                                                                                                                                                                                                          
        0x60b000010000-0x60c000000000                                                                                                                                                                                                                                          
        0x60c000000000-0x60c000010000                                                                                                                                                                                                                                          
        0x60c000010000-0x60d000000000                                                                                                                                                                                                                                          
        0x60d000000000-0x60d000010000                                                                                                                                                                                                                                          
        0x60d000010000-0x60e000000000                                                                                                                                                                                                                                          
        0x60e000000000-0x60e000010000                                                                                                                                                                                                                                          
        0x60e000010000-0x60f000000000                                                                                                                                                                                                                                          
        0x60f000000000-0x60f000010000                                                                                                                                                                                                                                          
        0x60f000010000-0x610000000000                                                                                                                                                                                                                                          
        0x610000000000-0x610000010000                                                                                                                                                                                                                                          
        0x610000010000-0x611000000000                                                                                                                                                                                                                                          
        0x611000000000-0x611000010000                                                                                                                                                                                                                                          
        0x611000010000-0x612000000000                                                                                                                                                                                                                                          
        0x612000000000-0x612000010000                                                                                                                                                                                                                                          
        0x612000010000-0x613000000000                                                                                                                                                                                                                                          
        0x613000000000-0x613000010000                                                                                                                                                                                                                                          
        0x613000010000-0x614000000000                                                                                                                                                                                                                                          
        0x614000000000-0x614000020000                                                                                                                                                                                                                                          
        0x614000020000-0x615000000000                                                                                                                                                                                                                                          
        0x615000000000-0x615000020000                                                                                                                                                                                                                                          
        0x615000020000-0x616000000000                                                                                                                                                                                                                                          
        0x616000000000-0x616000020000                                                                                                                                                                                                                                          
        0x616000020000-0x618000000000                                                                                                                                                                                                                                          
        0x618000000000-0x618000020000                                                                                                                                                                                                                                          
        0x618000020000-0x619000000000                                                                                                                                                                                                                                          
        0x619000000000-0x619000020000                                                                                                                                                                                                                                          
        0x619000020000-0x61a000000000                                                                                                                                                                                                                                          
        0x61a000000000-0x61a000020000                                                                                                                                                                                                                                          
        0x61a000020000-0x61b000000000
        0x61b000000000-0x61b000020000
        0x61b000020000-0x61d000000000
        0x61d000000000-0x61d000020000
        0x61d000020000-0x621000000000
        0x621000000000-0x621000020000
        0x621000020000-0x622000000000
        0x622000000000-0x622000020000
        0x622000020000-0x623000000000
        0x623000000000-0x623000020000
        0x623000020000-0x624000000000
        0x624000000000-0x624000020000
        0x624000020000-0x625000000000
        0x625000000000-0x625000020000
        0x625000020000-0x627000000000
        0x627000000000-0x627000030000
        0x627000030000-0x629000000000
        0x629000000000-0x629000010000
        0x629000010000-0x62f000000000
        0x62f000000000-0x62f000030000
        0x62f000030000-0x640000000000
        0x640000000000-0x640000003000
        0x7fa3c74b3000-0x7fa3c7517000   /usr/lib64/libtiff.so.5.2.4
        0x7fa3c7517000-0x7fa3c7717000   /usr/lib64/libtiff.so.5.2.4
        0x7fa3c7717000-0x7fa3c7718000   /usr/lib64/libtiff.so.5.2.4
        0x7fa3c7718000-0x7fa3c771b000   /usr/lib64/libtiff.so.5.2.4
        0x7fa3c771b000-0x7fa3c771c000
        0x7fa3c771c000-0x7fa3c7786000   /usr/lib64/ImageMagick-7.0.3/modules-Q64HDRI/coders/tiff.so
        0x7fa3c7786000-0x7fa3c7986000   /usr/lib64/ImageMagick-7.0.3/modules-Q64HDRI/coders/tiff.so
        0x7fa3c7986000-0x7fa3c7988000   /usr/lib64/ImageMagick-7.0.3/modules-Q64HDRI/coders/tiff.so
        0x7fa3c7988000-0x7fa3c798e000   /usr/lib64/ImageMagick-7.0.3/modules-Q64HDRI/coders/tiff.so
        0x7fa3c798e000-0x7fa3ce000000   /usr/lib64/locale/locale-archive
        0x7fa3ce000000-0x7fa3ce100000
        0x7fa3ce200000-0x7fa3ce300000
        0x7fa3ce31d000-0x7fa3d066f000
        0x7fa3d066f000-0x7fa3d0696000   /usr/lib64/libexpat.so.1.6.0
        0x7fa3d0696000-0x7fa3d0895000   /usr/lib64/libexpat.so.1.6.0
        0x7fa3d0895000-0x7fa3d0898000   /usr/lib64/libexpat.so.1.6.0
        0x7fa3d0898000-0x7fa3d0899000   /usr/lib64/libexpat.so.1.6.0
        0x7fa3d0899000-0x7fa3d09ce000   /usr/lib64/libglib-2.0.so.0.4600.2
        0x7fa3d09ce000-0x7fa3d0bce000   /usr/lib64/libglib-2.0.so.0.4600.2
        0x7fa3d0bce000-0x7fa3d0bcf000   /usr/lib64/libglib-2.0.so.0.4600.2
        0x7fa3d0bcf000-0x7fa3d0bd0000   /usr/lib64/libglib-2.0.so.0.4600.2
        0x7fa3d0bd0000-0x7fa3d0bd1000
        0x7fa3d0bd1000-0x7fa3d0bda000   /usr/lib64/libltdl.so.7.3.1
        0x7fa3d0bda000-0x7fa3d0dd9000   /usr/lib64/libltdl.so.7.3.1
        0x7fa3d0dd9000-0x7fa3d0dda000   /usr/lib64/libltdl.so.7.3.1
        0x7fa3d0dda000-0x7fa3d0ddb000   /usr/lib64/libltdl.so.7.3.1
        0x7fa3d0ddb000-0x7fa3d0df0000   /lib64/libz.so.1.2.8
        0x7fa3d0df0000-0x7fa3d0fef000   /lib64/libz.so.1.2.8
        0x7fa3d0fef000-0x7fa3d0ff0000   /lib64/libz.so.1.2.8
        0x7fa3d0ff0000-0x7fa3d0ff1000   /lib64/libz.so.1.2.8
        0x7fa3d0ff1000-0x7fa3d1000000   /lib64/libbz2.so.1.0.6
        0x7fa3d1000000-0x7fa3d11ff000   /lib64/libbz2.so.1.0.6
        0x7fa3d11ff000-0x7fa3d1200000   /lib64/libbz2.so.1.0.6
        0x7fa3d1200000-0x7fa3d1201000   /lib64/libbz2.so.1.0.6
        0x7fa3d1201000-0x7fa3d12a8000   /usr/lib64/libfreetype.so.6.12.3
        0x7fa3d12a8000-0x7fa3d14a8000   /usr/lib64/libfreetype.so.6.12.3
        0x7fa3d14a8000-0x7fa3d14ae000   /usr/lib64/libfreetype.so.6.12.3
        0x7fa3d14ae000-0x7fa3d14af000   /usr/lib64/libfreetype.so.6.12.3
        0x7fa3d14af000-0x7fa3d14ea000   /usr/lib64/libfontconfig.so.1.8.0
        0x7fa3d14ea000-0x7fa3d16e9000   /usr/lib64/libfontconfig.so.1.8.0
        0x7fa3d16e9000-0x7fa3d16eb000   /usr/lib64/libfontconfig.so.1.8.0
        0x7fa3d16eb000-0x7fa3d16ec000   /usr/lib64/libfontconfig.so.1.8.0
        0x7fa3d16ec000-0x7fa3d18e1000   /usr/lib64/libfftw3.so.3.4.4
        0x7fa3d18e1000-0x7fa3d1ae0000   /usr/lib64/libfftw3.so.3.4.4
        0x7fa3d1ae0000-0x7fa3d1af4000   /usr/lib64/libfftw3.so.3.4.4
        0x7fa3d1af4000-0x7fa3d1af5000   /usr/lib64/libfftw3.so.3.4.4
        0x7fa3d1af5000-0x7fa3d1b03000   /usr/lib64/liblqr-1.so.0.3.2
        0x7fa3d1b03000-0x7fa3d1d02000   /usr/lib64/liblqr-1.so.0.3.2
        0x7fa3d1d02000-0x7fa3d1d03000   /usr/lib64/liblqr-1.so.0.3.2
        0x7fa3d1d03000-0x7fa3d1d04000   /usr/lib64/liblqr-1.so.0.3.2
        0x7fa3d1d04000-0x7fa3d1d57000   /usr/lib64/liblcms2.so.2.0.6
        0x7fa3d1d57000-0x7fa3d1f57000   /usr/lib64/liblcms2.so.2.0.6
        0x7fa3d1f57000-0x7fa3d1f58000   /usr/lib64/liblcms2.so.2.0.6
        0x7fa3d1f58000-0x7fa3d1f5d000   /usr/lib64/liblcms2.so.2.0.6
        0x7fa3d1f5d000-0x7fa3d20f0000   /lib64/libc-2.22.so
        0x7fa3d20f0000-0x7fa3d22f0000   /lib64/libc-2.22.so
        0x7fa3d22f0000-0x7fa3d22f4000   /lib64/libc-2.22.so
        0x7fa3d22f4000-0x7fa3d22f6000   /lib64/libc-2.22.so
        0x7fa3d22f6000-0x7fa3d22fa000
        0x7fa3d22fa000-0x7fa3d2310000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7fa3d2310000-0x7fa3d250f000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7fa3d250f000-0x7fa3d2510000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7fa3d2510000-0x7fa3d2511000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7fa3d2511000-0x7fa3d2517000   /lib64/librt-2.22.so
        0x7fa3d2517000-0x7fa3d2717000   /lib64/librt-2.22.so
        0x7fa3d2717000-0x7fa3d2718000   /lib64/librt-2.22.so
        0x7fa3d2718000-0x7fa3d2719000   /lib64/librt-2.22.so
        0x7fa3d2719000-0x7fa3d2730000   /lib64/libpthread-2.22.so
        0x7fa3d2730000-0x7fa3d292f000   /lib64/libpthread-2.22.so
        0x7fa3d292f000-0x7fa3d2930000   /lib64/libpthread-2.22.so
        0x7fa3d2930000-0x7fa3d2931000   /lib64/libpthread-2.22.so
        0x7fa3d2931000-0x7fa3d2935000
        0x7fa3d2935000-0x7fa3d2a32000   /lib64/libm-2.22.so
        0x7fa3d2a32000-0x7fa3d2c31000   /lib64/libm-2.22.so
        0x7fa3d2c31000-0x7fa3d2c32000   /lib64/libm-2.22.so
        0x7fa3d2c32000-0x7fa3d2c33000   /lib64/libm-2.22.so
        0x7fa3d2c33000-0x7fa3d2c35000   /lib64/libdl-2.22.so
        0x7fa3d2c35000-0x7fa3d2e35000   /lib64/libdl-2.22.so
        0x7fa3d2e35000-0x7fa3d2e36000   /lib64/libdl-2.22.so
        0x7fa3d2e36000-0x7fa3d2e37000   /lib64/libdl-2.22.so
        0x7fa3d2e37000-0x7fa3d32fd000   /usr/lib64/libMagickWand-7.Q64HDRI.so.0.0.0
        0x7fa3d32fd000-0x7fa3d34fc000   /usr/lib64/libMagickWand-7.Q64HDRI.so.0.0.0
        0x7fa3d34fc000-0x7fa3d3511000   /usr/lib64/libMagickWand-7.Q64HDRI.so.0.0.0
        0x7fa3d3511000-0x7fa3d3553000   /usr/lib64/libMagickWand-7.Q64HDRI.so.0.0.0
        0x7fa3d3553000-0x7fa3d40e6000   /usr/lib64/libMagickCore-7.Q64HDRI.so.0.0.0
        0x7fa3d40e6000-0x7fa3d42e5000   /usr/lib64/libMagickCore-7.Q64HDRI.so.0.0.0
        0x7fa3d42e5000-0x7fa3d431e000   /usr/lib64/libMagickCore-7.Q64HDRI.so.0.0.0
        0x7fa3d431e000-0x7fa3d4390000   /usr/lib64/libMagickCore-7.Q64HDRI.so.0.0.0
        0x7fa3d4390000-0x7fa3d4393000
        0x7fa3d4393000-0x7fa3d43b5000   /lib64/ld-2.22.so
        0x7fa3d44ad000-0x7fa3d44cd000
        0x7fa3d44cd000-0x7fa3d44f0000   /usr/share/locale/it/LC_MESSAGES/libc.mo
        0x7fa3d44f0000-0x7fa3d44f1000
        0x7fa3d44f5000-0x7fa3d45a7000
        0x7fa3d45a7000-0x7fa3d45b4000
        0x7fa3d45b4000-0x7fa3d45b5000   /lib64/ld-2.22.so
        0x7fa3d45b5000-0x7fa3d45b6000   /lib64/ld-2.22.so
        0x7fa3d45b6000-0x7fa3d45b7000
        0x7fff923b9000-0x7fff923da000   [stack]
        0x7fff923de000-0x7fff923e0000   [vvar]
        0x7fff923e0000-0x7fff923e2000   [vdso]
        0xffffffffff600000-0xffffffffff601000   [vsyscall]
==26726==End of process memory map.
==26726==AddressSanitizer CHECK failed: /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:183 "((0 && "unable to mmap")) != (0)" (0x0, 0x0)
    #0 0x4c9f9d in AsanCheckFailed /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_rtl.cc:67
    #1 0x4d0ad3 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:159
    #2 0x4d0cc1 in __sanitizer::ReportMmapFailureAndDie(unsigned long, char const*, char const*, int, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:183
    #3 0x4d9cfa in __sanitizer::MmapOrDie(unsigned long, char const*, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix.cc:122
    #4 0x4244ea in __sanitizer::LargeMmapAllocator::Allocate(__sanitizer::AllocatorStats*, unsigned long, unsigned long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1033
    #5 0x4244ea in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback>, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> >, __sanitizer::LargeMmapAllocator >::Allocate(__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> >*, unsigned long, unsigned long, bool, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1302
    #6 0x4244ea in __asan::Allocator::Allocate(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:368
    #7 0x4c09e1 in realloc /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:79
    #8 0x7fa3c74badcb in _TIFFCheckRealloc /tmp/portage/media-libs/tiff-4.0.6/work/tiff-4.0.6/libtiff/tif_aux.c:73
    #9 0x7fa3c74c8599 in ChopUpSingleUncompressedStrip /tmp/portage/media-libs/tiff-4.0.6/work/tiff-4.0.6/libtiff/tif_dirread.c:5519
    #10 0x7fa3c74c8599 in TIFFReadDirectory /tmp/portage/media-libs/tiff-4.0.6/work/tiff-4.0.6/libtiff/tif_dirread.c:4032
    #11 0x7fa3c74e1d21 in TIFFClientOpen /tmp/portage/media-libs/tiff-4.0.6/work/tiff-4.0.6/libtiff/tif_open.c:466
    #12 0x7fa3c7731955 in ReadTIFFImage /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/coders/tiff.c:1160:8
    #13 0x7fa3d37beb12 in ReadImage /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/constitute.c:496:13
    #14 0x7fa3d3f56406 in ReadStream /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/stream.c:1012:9
    #15 0x7fa3d37bd5ca in PingImage /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/constitute.c:226:9
    #16 0x7fa3d37bde25 in PingImages /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/constitute.c:326:10
    #17 0x7fa3d30434c3 in IdentifyImageCommand /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickWand/identify.c:319:18
    #18 0x7fa3d30d926a in MagickCommandGenesis /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickWand/mogrify.c:183:14
    #19 0x4f1fb5 in MagickMain /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/utilities/magick.c:145:10
    #20 0x4f1fb5 in main /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/utilities/magick.c:176
    #21 0x7fa3d1f7d61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #22 0x419138 in _init (/usr/bin/magick+0x419138)
Affected version:
4.0.6

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00032-libtiff-memalloc-_TIFFCheckRealloc

Timeline:
2016-09-14: bug discovered
2016-11-04: bug reported to upstream
2016-11-09: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libtiff: memory allocation failure in _TIFFCheckRealloc (tif_aux.c)

Top

This week in vc4 (2016-11-07): glmark2, ETC1, power management, HDMI audio

Postby Eric Anholt via anholt's lj »

I spent a little bit of time last week on actual 3D work.  I finally figured out what was going wrong with glmark2's terrain demo.  The RCP (reciprocal) instruction on vc4 is a very rough approximation, and in translating GLSL code doing floating point divides (which we have to convert from a / b to a * (1 / b)) we use a Newton-Raphson step to improve our approximation.  However, we forgot to do this for the implicit divide we have to do at the end of your vertex shader, so the triangles in the distance were unstable and bounced around based on the error in the RCP output.

I also finally got around to writing kernel-side validation for ETC1 texture compression.  I should be able to merge support for this to v4.10, which is one of the feature checkboxes we were missing compared to the old driver.  Unfortunately ETC1 doesn't end up being very useful for us in open source stacks, because S3TC has been around a lot longer and supported on more hardware, so there's not much content using ETC that I know of outside of Android land.

I also spent a while fixing up various regressions that had happened in Mesa while I'd been playing in the kernel.  Some day I should work on CI infrastructure on real hardware, but unfortunately Mesa doesn't have any centralized CI infrastructure to plug into.  Intel has a test farm, but not all proposed patches get submitted to it, and it (understandably) doesn't have non-Intel hardware.

In kernel land, I sent out a patch to reduce V3D's overhead due to power management.  We were immediately shutting off the 3D engine when it went idle, even if userland might be expected to submit a new frame shortly thereafter.  This was taking up 1% of the CPU on profiles I was looking at last week, and I've seen it up to 3.5%.  Now we keep the GPU on for at least 40ms ("about two frames plus some slack").  If I'm reading right, the closed driver does immediate powerdown as well, so we may be using slightly more power now, but given that power state transitions themselves cost power, and the CPU overhead costs power, hopefully this works out fine anyway (even though we've never done power measurements for the platform).

I also reviewed more patches from Michael Zoran for vchiq.  It should now (once all reviewed patches land) work on arm64.  We still need to get the vchiq-using drivers like camera and vcsm into staging.

Finally, I made more progress on HDMI audio.  One of the ALSA developers, Lars-Peter Clausen, pointed out that ALSA's design is that userspace would provide the IEC958 subframes by using alsalib's iec958 plugin and a bit ouf asoundrc configuration.  He also provided a ton of help debugging that pipeline.  I rebased and cleaned up into a branch that uses simple-audio-card as my machine driver, so the whole stack is pretty trivial.  Now aplay runs successfully, though no sound has come out.  Next step is to go test that the closed stack actually plays audio on this monitor and capture some register state for debugging.
Top

libming: listmp3: global-buffer-overflow in printMP3Headers (listmp3.c)

Postby ago via agostino's blog »

Description:
libming is a Flash (SWF) output library. It can be used from PHP, Perl, Ruby, Python, C, C++, Java, and probably more on the way..

A fuzzing revealed a global buffer overflow in listmp3. The bug does not reside in any shared object but if you have a web application that calls directly the listmp3 binary to parse untrusted mp3, then you are affected.

The complete ASan output:

# listmp3 $FILE
==29519==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000722e0c at pc 0x0000004f1a99 bp 0x7ffe42b1d7f0 sp 0x7ffe42b1d7e8
READ of size 4 at 0x000000722e0c thread T0
    #0 0x4f1a98 in printMP3Headers /var/tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/listmp3.c:128:20
    #1 0x4f1bee in main /var/tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/listmp3.c:191:3
    #2 0x7fe262a4761f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #3 0x418ae8 in getenv (/usr/bin/listmp3+0x418ae8)

0x000000722e0c is located 52 bytes to the left of global variable 'mp2_samplerate_table' defined in 'listmp3.c:44:5' (0x722e40) of size 12
0x000000722e0c is located 0 bytes to the right of global variable 'mp1_samplerate_table' defined in 'listmp3.c:43:5' (0x722e00) of size 12
SUMMARY: AddressSanitizer: global-buffer-overflow /var/tmp/portage/media-libs/ming-0.4.7/work/ming-0_4_7/util/listmp3.c:128:20 in printMP3Headers
Shadow bytes around the buggy address:
  0x0000800dc570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800dc580: 00 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9
  0x0000800dc590: 00 00 00 00 00 00 00 04 f9 f9 f9 f9 00 00 00 00
  0x0000800dc5a0: 00 00 00 04 f9 f9 f9 f9 00 00 00 00 00 00 00 04
  0x0000800dc5b0: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9
=>0x0000800dc5c0: 00[04]f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9
  0x0000800dc5d0: 00 04 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x0000800dc5e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800dc5f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800dc600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800dc610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2                                                                                                                                                                                                                                                  
  Stack right redzone:     f3                                                                                                                                                                                                                                                  
  Stack partial redzone:   f4                                                                                                                                                                                                                                                  
  Stack after return:      f5                                                                                                                                                                                                                                                  
  Stack use after scope:   f8                                                                                                                                                                                                                                                  
  Global redzone:          f9                                                                                                                                                                                                                                                  
  Global init order:       f6                                                                                                                                                                                                                                                  
  Poisoned by user:        f7                                                                                                                                                                                                                                                  
  Container overflow:      fc                                                                                                                                                                                                                                                  
  Array cookie:            ac                                                                                                                                                                                                                                                  
  Intra object redzone:    bb                                                                                                                                                                                                                                                  
  ASan internal:           fe                                                                                                                                                                                                                                                  
  Left alloca redzone:     ca                                                                                                                                                                                                                                                  
  Right alloca redzone:    cb                                                                                                                                                                                                                                                  
==29519==ABORTING                                                                                                                                                                                                                                                              
frame 1: MP25 layer 1, 8000 Hz, 0kbps, mono, length=0, protect off
Affected version:
0.4.7

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-9264

Reproducer:
https://github.com/asarubbo/poc/blob/master/00034-libming-globaloverflow-printMP3Headers

Timeline:
2016-08-13: bug discovered
2016-10-20: bug reported to upstream
2016-11-07: blog post about the issue
2016-11-10: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libming: listmp3: global-buffer-overflow in printMP3Headers (listmp3.c)

Top

libdwarf: memory allocation failure in do_decompress_zlib (dwarf_init_finish.c)

Postby ago via agostino's blog »

Description:
libdwarf is a library to consume and produce DWARF debug information.

A fuzz on an updated version revealed a memory allocation failure.

The complete ASan output:

# dwarfdump $FILE
==27994==WARNING: AddressSanitizer failed to allocate 0x62696c2f7273752f bytes 
==27994==AddressSanitizer's allocator is terminating the process instead of returning 0 
==27994==If you don't like this behavior set allocator_may_return_null=1 
==27994==AddressSanitizer CHECK failed: /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:147 "((0)) != (0)" (0x0, 0x0) 
   #0 0x4ca3ed in __asan::AsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_rtl.cc:67 
   #1 0x4d0f23 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:159 
   #2 0x4cec76 in __sanitizer::ReportAllocatorCannotReturnNull() /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:147 
   #3 0x42204c in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback>, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> >, __sanitizer::LargeMmapAllocator >::ReturnNullOrDie() /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1317 
   #4 0x42204c in __asan::Allocator::Allocate(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:359 
   #5 0x42204c in __asan::asan_malloc(unsigned long, __sanitizer::BufferedStackTrace*) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:718 
   #6 0x4c0ab1 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:53 
   #7 0x5b582e in do_decompress_zlib /tmp/dwarf-20161021/libdwarf/dwarf_init_finish.c:1085:12 
   #8 0x5b582e in _dwarf_load_section /tmp/dwarf-20161021/libdwarf/dwarf_init_finish.c:1159 
   #9 0x5bb479 in dwarf_srcfiles /tmp/dwarf-20161021/libdwarf/./dwarf_line.c:336:11 
   #10 0x5145cd in print_one_die_section /tmp/dwarf-20161021/dwarfdump/print_die.c:812:28 
   #11 0x512262 in print_infos /tmp/dwarf-20161021/dwarfdump/print_die.c:371:16 
   #12 0x4faafa in process_one_file /tmp/dwarf-20161021/dwarfdump/dwarfdump.c:1371:9 
   #13 0x4faafa in main /tmp/dwarf-20161021/dwarfdump/dwarfdump.c:654 
   #14 0x7f578f45a61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289 
   #15 0x419588 in _start (/usr/bin/dwarfdump-asan+0x419588)
Affected version:
20161021

Fixed version:
N/A

Commit fix:
https://sourceforge.net/p/libdwarf/code/ci/583f8834083b5ef834c497f5b47797e16101a9a6/

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00024-libdwarf-memalloc-do_decompress_zlib

Timeline:
2016-11-02: bug discovered and reported to upstream
2016-11-05: upstream released a patch
2016-11-07: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libdwarf: memory allocation failure in do_decompress_zlib (dwarf_init_finish.c)

Top

libdwarf: heap-based buffer overflow in dwarf_get_aranges_list (dwarf_arange.c)

Postby ago via agostino's blog »

Description:
libdwarf is a library to consume and produce DWARF debug information.

A fuzz on an updated version revealed a buffer overflow.

The complete ASan output:

# dwarfdump $FILE
==27460==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60600000eff4 at pc 0x00000047349b bp 0x7ffd9feadaf0 sp 0x7ffd9fead2a0
READ of size 2 at 0x60600000eff4 thread T0
    #0 0x47349a in memcpy /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:438
    #1 0x56cbe0 in dwarf_get_aranges_list /tmp/dwarf-20161021/libdwarf/dwarf_arange.c:118:9
    #2 0x56c0dc in dwarf_get_aranges /tmp/dwarf-20161021/libdwarf/dwarf_arange.c:318:11
    #3 0x50f103 in print_aranges /tmp/dwarf-20161021/dwarfdump/print_aranges.c:145:12
    #4 0x4fb2bf in process_one_file /tmp/dwarf-20161021/dwarfdump/dwarfdump.c:1420:9
    #5 0x4fb2bf in main /tmp/dwarf-20161021/dwarfdump/dwarfdump.c:654
    #6 0x7f2b42a4461f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #7 0x419588 in _start (/usr/bin/dwarfdump-asan+0x419588)

0x60600000eff4 is located 0 bytes to the right of 52-byte region [0x60600000efc0,0x60600000eff4)
allocated by thread T0 here:
    #0 0x4c0ad8 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52
    #1 0x7f2b43b1e206 in __libelf_set_rawdata_wrlock /tmp/portage/dev-libs/elfutils-0.166/work/elfutils-0.166/libelf/elf_getdata.c:318

SUMMARY: AddressSanitizer: heap-buffer-overflow 
/var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:438 in memcpy
Shadow bytes around the buggy address:
  0x0c0c7fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff9de0: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
=>0x0c0c7fff9df0: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00[04]fa
  0x0c0c7fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==27460==ABORTING
Affected version:
20161021

Fixed version:
N/A

Commit fix:
https://sourceforge.net/p/libdwarf/code/ci/583f8834083b5ef834c497f5b47797e16101a9a6/

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-9276

Reproducer:
https://github.com/asarubbo/poc/blob/master/00026-libdwarf-heapoverflow-dwarf_get_aranges_list


Timeline:
2016-11-02: bug discovered and reported to upstream
2016-11-05: upstream released a patch
2016-11-07: blog post about the issue
2016-11-11: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libdwarf: heap-based buffer overflow in dwarf_get_aranges_list (dwarf_arange.c)

Top

libdwarf: heap-based buffer overflow in get_attr_value (print_die.c)

Postby ago via agostino's blog »

Description:
libdwarf is a library to consume and produce DWARF debug information.

A fuzz on an updated version revealed a buffer overflow.

The complete ASan output:

# dwarfdump $FILE
==27395==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61300000de1c at pc 0x000000528cd3 bp 0x7ffd980a63b0 sp 0x7ffd980a63a8
READ of size 1 at 0x61300000de1c thread T0
    #0 0x528cd2 in get_attr_value /tmp/dwarf-20161021/dwarfdump/print_die.c:4978:21
    #1 0x51e4a4 in print_attribute /tmp/dwarf-20161021/dwarfdump/print_die.c:3357:13
    #2 0x51a651 in print_one_die /tmp/dwarf-20161021/dwarfdump/print_die.c:1458:38
    #3 0x51710c in print_die_and_children_internal /tmp/dwarf-20161021/dwarfdump/print_die.c:1047:36
    #4 0x517c6b in print_die_and_children_internal /tmp/dwarf-20161021/dwarfdump/print_die.c:1142:13
    #5 0x5147cc in print_die_and_children /tmp/dwarf-20161021/dwarfdump/print_die.c:921:5
    #6 0x5147cc in print_one_die_section /tmp/dwarf-20161021/dwarfdump/print_die.c:831
    #7 0x512262 in print_infos /tmp/dwarf-20161021/dwarfdump/print_die.c:371:16
    #8 0x4faafa in process_one_file /tmp/dwarf-20161021/dwarfdump/dwarfdump.c:1371:9
    #9 0x4faafa in main /tmp/dwarf-20161021/dwarfdump/dwarfdump.c:654
    #10 0x7f883beec61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #11 0x419588 in _start (/usr/bin/dwarfdump-asan+0x419588)

0x61300000de1c is located 0 bytes to the right of 348-byte region [0x61300000dcc0,0x61300000de1c)
allocated by thread T0 here:
    #0 0x4c0ad8 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52
    #1 0x7f883cfc6206 in __libelf_set_rawdata_wrlock /tmp/portage/dev-libs/elfutils-0.166/work/elfutils-0.166/libelf/elf_getdata.c:318

SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/dwarf-20161021/dwarfdump/print_die.c:4978:21 in get_attr_value
Shadow bytes around the buggy address:
  0x0c267fff9b70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c267fff9b80: 00 00 00 00 00 00 00 00 00 00 03 fa fa fa fa fa
  0x0c267fff9b90: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c267fff9ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c267fff9bb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c267fff9bc0: 00 00 00[04]fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c267fff9bd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c267fff9be0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c267fff9bf0: 00 00 00 00 00 00 00 00 00 00 00 03 fa fa fa fa
  0x0c267fff9c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c267fff9c10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==27395==ABORTING
Affected version:
20161021

Fixed version:
N/A

Commit fix:
https://sourceforge.net/p/libdwarf/code/ci/583f8834083b5ef834c497f5b47797e16101a9a6/

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00025-libdwarf-heapoverflow-get_attr_value


Timeline:
2016-11-02: bug discovered and reported to upstream
2016-11-05: upstream released a patch
2016-11-07: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libdwarf: heap-based buffer overflow in get_attr_value (print_die.c)

Top

libdwarf: heap-based buffer overflow in _dwarf_skim_forms (dwarf_macro5.c)

Postby ago via agostino's blog »

Description:
libdwarf is a library to consume and produce DWARF debug information.

A fuzz on an updated version revealed a buffer overflow.

The complete ASan output:

# dwarfdump $FILE
==2437==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62000000fe5b at pc 0x000000462c7c bp 0x7ffea0d4b690 sp 0x7ffea0d4ae40
READ of size 29 at 0x62000000fe5b thread T0
    #0 0x462c7b in __interceptor_strlen /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:581
    #1 0x5edea2 in _dwarf_skim_forms /tmp/dwarf-20161021/libdwarf/dwarf_macro5.c:185:17
    #2 0x5edea2 in _dwarf_get_macro_ops_count_internal /tmp/dwarf-20161021/libdwarf/dwarf_macro5.c:346
    #3 0x5eb886 in _dwarf_internal_macro_context_by_offset /tmp/dwarf-20161021/libdwarf/dwarf_macro5.c:1338:11
    #4 0x5eb886 in _dwarf_internal_macro_context /tmp/dwarf-20161021/libdwarf/dwarf_macro5.c:1201
    #5 0x5ed10e in dwarf_get_macro_context_by_offset /tmp/dwarf-20161021/libdwarf/dwarf_macro5.c:1467:11
    #6 0x54f7be in print_macros_5style_this_cu /tmp/dwarf-20161021/dwarfdump/print_macro.c:288:16
    #7 0x514d0f in print_one_die_section /tmp/dwarf-20161021/dwarfdump/print_die.c:869:21
    #8 0x512262 in print_infos /tmp/dwarf-20161021/dwarfdump/print_die.c:371:16
    #9 0x4faafa in process_one_file /tmp/dwarf-20161021/dwarfdump/dwarfdump.c:1371:9
    #10 0x4faafa in main /tmp/dwarf-20161021/dwarfdump/dwarfdump.c:654
    #11 0x7f74b22e761f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #12 0x419588 in _start (/usr/bin/dwarfdump-asan+0x419588)

0x62000000fe5b is located 0 bytes to the right of 3547-byte region [0x62000000f080,0x62000000fe5b)
allocated by thread T0 here:
    #0 0x4c0ad8 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52
    #1 0x7f74b33c1206 in __libelf_set_rawdata_wrlock /tmp/portage/dev-libs/elfutils-0.166/work/elfutils-0.166/libelf/elf_getdata.c:318

SUMMARY: AddressSanitizer: heap-buffer-overflow /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:581 in __interceptor_strlen
Shadow bytes around the buggy address:
  0x0c407fff9f70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c407fff9f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c407fff9f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c407fff9fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c407fff9fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c407fff9fc0: 00 00 00 00 00 00 00 00 00 00 00[03]fa fa fa fa
  0x0c407fff9fd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c407fff9fe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c407fff9ff0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c407fffa000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c407fffa010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==2437==ABORTING
Affected version:
20161021

Fixed version:
N/A

Commit fix:
https://sourceforge.net/p/libdwarf/code/ci/583f8834083b5ef834c497f5b47797e16101a9a6/

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-9275

Reproducer:
https://github.com/asarubbo/poc/blob/master/00027-libdwarf-heapoverflow-_dwarf_skim_forms

Timeline:
2016-11-02: bug discovered and reported to upstream
2016-11-05: upstream released a patch
2016-11-07: blog post about the issue
2016-11-11: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libdwarf: heap-based buffer overflow in _dwarf_skim_forms (dwarf_macro5.c)

Top

jasper: use after free in jas_realloc (jas_malloc.c)

Postby ago via agostino's blog »

Description:
jasper is an open-source initiative to provide a free software-based reference implementation of the codec specified in the JPEG-2000 Part-1 standard.

A crafted image, maybe posted in the past as testcase for another bug, causes in the 1.900.18 version a use-after-free. No fuzzers involved at this time.

The complete ASan output:

# imginfo -f $FILE
Corrupt JPEG data: 19 extraneous bytes before marker 0xda                                                                                                                                                                                                                      
=================================================================                                                                                                                                                                                                              
==21990==ERROR: AddressSanitizer: heap-use-after-free on address 0x619000009b80 at pc 0x7fce4229d29d bp 0x7fffab22f9a0 sp 0x7fffab22f998                                                                                                                                       
READ of size 8 at 0x619000009b80 thread T0                                                                                                                                                                                                                                     
    #0 0x7fce4229d29c in jas_realloc /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/base/jas_malloc.c:182:21                                                                                                                                       
    #1 0x7fce422a5e38 in mem_resize /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/base/jas_stream.c:1001:14                                                                                                                                       
    #2 0x7fce422a5e38 in mem_write /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/base/jas_stream.c:1027                                                                                                                                           
    #3 0x7fce422a30e5 in jas_stream_flushbuf /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/base/jas_stream.c:822:7                                                                                                                                
    #4 0x7fce422a4b4c in jas_stream_flush /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/base/jas_stream.c:752:9                                                                                                                                   
    #5 0x7fce422a4b4c in jas_stream_seek /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/base/jas_stream.c:659                                                                                                                                      
    #6 0x7fce42273928 in jas_image_cmpt_create /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/base/jas_image.c:351:4                                                                                                                               
    #7 0x7fce42276986 in jas_image_addcmpt /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/base/jas_image.c:723:18                                                                                                                                  
    #8 0x7fce4233e3fc in jpg_mkimage /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/jpg/jpg_dec.c:268:7                                                                                                                                            
    #9 0x7fce4233e3fc in jpg_decode /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/jpg/jpg_dec.c:183                                                                                                                                               
    #10 0x7fce422749bd in jas_image_decode /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/base/jas_image.c:396:16                                                                                                                                  
    #11 0x4f1330 in main /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/appl/imginfo.c:203:16                                                                                                                                                                
    #12 0x7fce4138961f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                                                                                                       
    #13 0x418cb8 in _init (/usr/bin/imginfo+0x418cb8)                                                                                                                                                                                                                          
                                                                                                                                                                                                                                                                               
0x619000009b80 is located 0 bytes inside of 1056-byte region [0x619000009b80,0x619000009fa0)                                                                                                                                                                                   
freed by thread T0 here:                                                                                                                                                                                                                                                       
    #0 0x4bff00 in free /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:38                                                                                                                                     
    #1 0x7fce4229d359 in jas_free /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/base/jas_malloc.c:225:3                                                                                                                                           
                                                                                                                                                                                                                                                                               
previously allocated by thread T0 here:                                                                                                                                                                                                                                        
    #0 0x4c0208 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52                                                                                                                                   
    #1 0x7fce4229d0b2 in jas_malloc /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/base/jas_malloc.c:148:13                                                                                                                                        
                                                                                                                                                                                                                                                                               
SUMMARY: AddressSanitizer: heap-use-after-free /tmp/portage/media-libs/jasper-1.900.18/work/jasper-1.900.18/src/libjasper/base/jas_malloc.c:182:21 in jas_realloc                                                                                                              
Shadow bytes around the buggy address:                                                                                                                                                                                                                                         
  0x0c327fff9320: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa                                                                                                                                                                                                              
  0x0c327fff9330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa                                                                                                                                                                                                              
  0x0c327fff9340: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa                                                                                                                                                                                                              
  0x0c327fff9350: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa                                                                                                                                                                                                              
  0x0c327fff9360: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa                                                                                                                                                                                                              
=>0x0c327fff9370:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd                                                                                                                                                                                                              
  0x0c327fff9380: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd                                                                                                                                                                                                              
  0x0c327fff9390: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd                                                                                                                                                                                                              
  0x0c327fff93a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd                                                                                                                                                                                                              
  0x0c327fff93b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd                                                                                                                                                                                                              
  0x0c327fff93c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd                                                                                                                                                                                                              
Shadow byte legend (one shadow byte represents 8 application bytes):                                                                                                                                                                                                           
  Addressable:           00                                                                                                                                                                                                                                                    
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==21990==ABORTING
Affected version:
1.900.18

Fixed version:
1.900.22

Commit fix:
https://github.com/mdadams/jasper/commit/634ce8e8a5accc0fa05dd2c20d42b4749d4b2735

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-9262

Reproducer:
https://github.com/asarubbo/poc/blob/master/00028-jasper-uaf-jas_realloc

Timeline:
2016-11-02: bug discovered and reported to upstream
2016-11-06: upstream released a patch and 1.900.22
2016-11-07: blog post about the issue
2016-11-10: CVE assigned

Note:
This bug was found with Address Sanitizer.

Permalink:

jasper: use after free in jas_realloc (jas_malloc.c)

Top

iocage: HOWTO create a basejail from src (instead of from an official release)

Postby netchild via Alexander Leidinger »

Background

So far I have used ezjail to manage FreeBSD jails. I use jails since years to have different parts of a software stack in some kind of a container (in a ZFS dataset for the filesystem side of the container). On one hand to not let dependencies of one part of the software stack have influence of other parts of the software stack. On the other hand to have the possibility to move parts of the software stack to a different system if necessary. Normally I run -stable or -current or more generally speaking, a self-compiled FreeBSD on those systems. In ezjail I like the fact that all jails on a system have one common basejail underlying, so that I update one place for the userland and all jails get the updated code.

Since a while I heard good things about iocage and how it integrates ZFS, so I decided to give it a try myself. As iocage does not come with an official way of creating a basejail (respectively a release) from a self-compiled FreeBSD (at least documented in those places I looked, and yes, I am aware that I can create a FreeBSD release myself and use it, but I do not like to have to create a release additionally to the buildworld I use to update the host system) here now the short HOWTO achieve this.

Invariants

In the following I assume the iocage ZFS parts are already created in dataset ${POOLNAME}/iocage which is mounted on ${IOCAGE_BASE}/iocage. Additionally the buildworld in /usr/src (or wherever you have the FreeBSD source) should be finished.

Pre-requisites

To have the necessary dataset-infrastructure created for own basejails/releases, at least one official release needs to be fetched before. So run the command below (if there is no ${IOCAGE_BASE}/iocage/releases directory) and follow the on-screen instructions.

iocage fetch

HOWTO

Some variables:

POOLNAME=mpool
SRC_REV=r$(cd /usr/src; svnliteversion)
IOCAGE_BASE=””
Creating the iocage basejail-datasets for this ${SRC_REV}:

zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/bin
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/boot
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/lib
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/libexec
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/rescue
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/sbin
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/usr
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/usr/bin
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/usr/include
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/usr/lib
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/usr/lib32
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/usr/libdata
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/usr/libexec
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/usr/sbin
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/usr/share
zfs create –o compression=lz4 ${POOLNAME}/iocage/base/${SRC_REV}-RELEASE/root/usr/src
Install from /usr/src (the executable “chown” is hardlinked across an iocage basejail dataset boundary, this fails in the normal installworld, so we have to ignore this error and install a copy of the chown binary to the place where the hardlink normally is):

cd /usr/src
make –i installworld DESTDIR=${IOCAGE_BASE}/iocage/base/${SRC_REV}-RELEASE/root >&! iocage_installworld_base.log
cp –pv ${IOCAGE_BASE}/iocage/base/${SRC_REV}-RELEASE/root/usr/sbin/chown ${IOCAGE_BASE}/iocage/base/${SRC_REV}-RELEASE/root/usr/bin/chgrp
make distribution DESTDIR=${IOCAGE_BASE}/iocage/base/${SRC_REV}-RELEASE/root »& iocage_installworld_base.log
While we are here, also create a release and not only a basejail:

zfs create –o compression=lz4 ${POOLNAME}/iocage/releases/${SRC_REV}-RELEASE
zfs create –o compression=lz4 ${POOLNAME}/iocage/releases/${SRC_REV}-RELEASE/root
make installworld DESTDIR=${IOCAGE_BASE}/iocage/releases/${SRC_REV}-RELEASE/root >&! iocage_installworld_release.log
make distribution DESTDIR=${IOCAGE_BASE}/iocage/releases/${SRC_REV}-RELEASE/root »& iocage_installworld_release.log
And finally make this the default release which iocage uses when creating new jails (this is optional):

iocage set release=${SRC_REV}-RELEASE default
Now the self-build FreeBSD is available in iocage for new jails.



Top

SCALE 15x CFP is closing soon

Postby calchan via Denis Dupeyron »

Just a quick reminder that the deadline for proposing a talk to SCALE 15x is on November 15th. More information, including topics of interest, is available on the SCALE website.

SCALE 15x is to be held on March 2-5, 2017 at the Pasadena Convention Center in Pasadena, California, near Los Angeles. This is the same venue as last year and is much nicer than the original one form the years before.

I’ll see you there.
Top

HOWTO: “Blind” re­mote in­stall of FreeBSD via tiny disk im­age (ZFS edition)

Postby netchild via Alexander Leidinger »

In a past post I described how to install a FreeBSD remotely via a tiny UFS based disk image over a linux system. In this post I describe how to do it with a ZFS based disk image.

Invariants

Given a unix based remote system (in this case a linux system) from which you know what kind of hardware it runs on (e.g. PCI IDs) and what the corresponding FreeBSD drivers are.

HOWTO

In the title of this post I wrote “via a tiny disk im­age”. This is true for a suit­able defin­i­tion of tiny.

What we have in the root­server are two ~900 GB hard­disks. They shall be used in a soft­ware mir­ror. The ma­chine has 8 GB of RAM. I do not ex­pect much ker­nel pan­ics (= crash dumps) there, so we do not really need >8 GB of swap (for­get the rule of hav­ing twice as much swap than RAM, with the cur­rent amount of RAM in a ma­chine you are in “trouble” when you need even the same amount of swap than RAM). I de­cided to go with 2 GB of swap.

Pushing/pulling a 900 GB im­age over the net­work to in­stall a sys­tem is not really some­thing I want to do. I am OK to transfer 5 GB (that is 0.5% of the en­tire disk) to get this job done, and this is feas­ible.

First let us define some vari­ables in the shell, this way you just need to change the val­ues in one place and the rest is copy&paste (I use the SVN revision of the source which I use to install the system as the name of the sysutils/beadm compatible boot-dataset in the rootfs, as such I also have the revision number available in a variable):

ROOTFS_SIZE=5G
ROOTFS_NAME=root
FILENAME=rootfs
POOLNAME=mpool
VERSION=r$(cd /usr/src; svnliteversion)
SWAPSIZE=2G
Then change your cur­rent dir­ect­ory to a place where you have enough space for the im­age. There we will cre­ate a con­tainer for the im­age, and make it ready for par­ti­tion­ing:

truncate –s ${ROOTFS_SIZE} ${FILENAME}
mdconfig –a –t vnode –f ${FILENAME}
# if you want to fully allocate
# dd if=/dev/zero of=/dev/md0 bs=1m
Cre­ate the partition table and the rootfs (in a sysutils/beadm compatible way — as I install FreeBSD-current there — and mount it temporary to /temppool):

gpart create –s GPT /dev/md0
gpart add –s 512K –t freebsd-boot –l bootcode0 /dev/md0
gpart add –a 4k –t freebsd-swap –s ${SWAPSIZE} –l swap0 /dev/md0
gpart add –a 1m –t freebsd-zfs –l ${POOLNAME}0 /dev/md0
gpart bootcode –b /boot/pmbr –p /boot/gptzfsboot –i 1 /dev/md0
# if not already the case and you want to have 4k physical sector size of the pool
# syscl vfs.zfs.min_auto_ashift=12
zpool create –o cachefile=/boot/zfs/zpool.cache_temp –o altroot=/temppool –O compress=lz4 –O atime=off –O utf8only=on ${POOLNAME} /dev/gpt/${POOLNAME}0
zfs create –o mountpoint=none ${POOLNAME}/ROOT
zfs create –o mountpoint=/ ${POOLNAME}/ROOT/${VERSION}
zfs create –o mountpoint=/tmp –o exec=on –o setuid=off ${POOLNAME}/tmp
zfs create –o mountpoint=/usr –o canmount=off ${POOLNAME}/usr
zfs create –o mountpoint=/home ${POOLNAME}/home
zfs create –o setuid=off ${POOLNAME}/usr/ports
zfs create ${POOLNAME}/usr/src
zfs create –o mountpoint=/var –o canmount=off ${POOLNAME}/var
zfs create –o exec=off –o setuid=off ${POOLNAME}/var/audit
zfs create –o exec=off –o setuid=off ${POOLNAME}/var/crash
zfs create –o exec=off –o setuid=off ${POOLNAME}/var/log
zfs create –o atime=on ${POOLNAME}/var/mail
zfs create –o setuid=off ${POOLNAME}/var/tmp
zfs create ${POOLNAME}/var/ports
zfs create –o exec=off –o setuid=off –o mountpoint=/shared ${POOLNAME}/shared
zfs create –o exec=off –o setuid=off ${POOLNAME}/shared/distfiles
zfs create –o exec=off –o setuid=off ${POOLNAME}/shared/packages
zfs create –o exec=off –o setuid=off –o compression=lz4 ${POOLNAME}/shared/ccache
zfs create ${POOLNAME}/usr/obj
zpool set bootfs=${POOLNAME}/ROOT/${VERSION} ${POOLNAME}
In­stall FreeBSD (from source):

cd /usr/src
#make buildworld >&! buildworld.log
#make buildkernel –j 8 KERNCONF=GENERIC >&! buildkernel_generic.log
make installworld DESTDIR=/temppool/ >& installworld.log
make distribution DESTDIR=/temppool/ >& distrib.log
make installkernel KERNCONF=GENERIC DESTDIR=/temppool/ >& installkernel.log
Copy the temporary zpool cache created above in the pool-creation part to the image (I have the impression it is not really needed and will work without, but I have not tried this):

cp /boot/zfs/zpool.cache_temp /temppool/boot/
cp /boot/zfs/zpool.cache_temp /temppool/boot/zpool.cache
Add the zfs module to loader.conf:

zfs_load=“yes“
opensolaris_load=“yes”
Now you need to create /temppool/etc/rc.conf (set the de­faultrouter, the IP ad­dress via ifconfig_IF (and do not for­get to use the right IF for it), the host­name, set sshd_enable to yes, zfs_enable=”YES”)  /temppool/boot/loader.conf (zfs_load=”yes”, opensolaris_load=”yes”, vfs.root.mountfrom=”zfs:${POOLNAME}/ROOT/r${VERSION}”)
/temppool/etc/hosts, /temppool/etc/resolv.conf and maybe /temppool/etc/sysctl.conf and /temppool/etc/periodic.conf.

Do not allow password-less root logins in single-user mode on the physical console, create a resolv.conf and an user:

cd /temppool/etc
sed –ie „s:console.*off.:&in:“ ttys
cat >resolv.conf «EOT
search YOURDOMAIN
nameserver 8.8.8.8
EOT
pw –V /temppool/etc groupadd YOURGROUP –g 1001
pw –V /temppool/etc useradd YOURUSER –u 1001 –d /home/YOURUSER –g YOURUSER –G wheel –s /bin/tcsh
pw –V /temppool/etc usermod YOURUSER –h 0
pw –V /temppool/etc usermod root –h 0
zfs create mpool/home/YOURUSER
chown YOURUSER:YOURGROUP /temppool/home/YOURUSER
Now you can make some more modifications to the system if wanted, and then export the pool and detach the image:

zpool export ${POOLNAME}

mdconfig –d –u 0
Depending on the upload speed you can achieve, it is beneficial to compress the image now, e.g. with bzip2. Then transfer the image to the disk of the remote system. In my case I did this via:

ssh –C –o CompressionLevel=9 root@remote_host dd of=/dev/hda bs=1m < /path/to/${FILENAME}
Then reboot/power-cycle the remote system.

Post-install tasks

Now we have a new FreeBSD system which uses only a fraction of the the harddisk and is not resilient against harddisk-failures.

FreeBSD will detect that the disk is bigger than the image we used when creating the GPT label and warn about it (corrupt GPT table). To fix this and to resize the partition for the zpool to use the entire disk we first mirror the zpool to the second disk and resize the partition of the first disk, and when the zpool is in-sync and then we resize the boot disk (attention, you need to change the “-s” part in the following to match your disk size).

First backup the label of the first disk, this makes it more easy to create the label of the second disk:

/sbin/gpart backup ada0 > ada0.gpart
Edit ada0.gpart (give different names for the labels, mainly change the number 0 on the label-name to 1) and then use it to create the partition of the second disk:

gpart restore –Fl ada1 < ada0.gpart
gpart resize –i 3 –a 4k –s 929g ada1
gpart bootcode –b /boot/pmbr –p /boot/gptzfsboot –i 1 ada1
zpool set autoexpand=on mpool
Fix the warning about the GPT label and resize the partition:

gpart recover ada0
gpart resize –i 3 –a 4k –s 929g ada0
Afterwards it should look similar to this:

gpart show –l
=>        40  1953525088  ada0  GPT  (932G)
          40        1024     1  bootcode0  (512K)
        1064     4194304     2  swap0  (2.0G)
     4195368         984        – free –  (492K)
     4196352  1948254208     3  mpool0  (929G)
  1952450560     1074568        – free –  (525M)

=>        40  1953525088  ada1  GPT  (932G)
          40        1024     1  bootcode1  (512K)
        1064     4194304     2  swap1  (2.0G)
     4195368         984        – free –  (492K)
     4196352  1948254208     3  mpool1  (929G)
  1952450560     1074568        – free –  (525M)
Add the second disk to the zpool:

zpool attach mpool gpt/mpool0 gpt/mpool1
When the mirror is in sync (zpool status mpool), we can extend the size of the pool itself:

zpool offline mpool /dev/gpt/mpool0
zpool online mpool /dev/gpt/mpool0
As a last step we can add now an encrypted swap (depending on the importance of the system maybe a gmirror-ed one — not explained here), and specify where to dump (text-dumps) on.

/boot/loader.conf:

dumpdev=”/dev/ada0p2”
/etc/rc.conf:

dumpdev=”/dev/gpt/swap0“
crashinfo_enable=“YES“
ddb_enable=“yes“
encswap_enable=“YES“
geli_swap_flags=”-a hmac/sha256 –l 256 –s 4096 –d”
/etc/fstab:

# Device        Mountpoint      FStype  Options                 Dump    Pass#
/dev/ada1p2.eli none    swap    sw      0       0
Now the system is ready for some applications.



Top

Did the Mirai Botnet Really Take Liberia Offline?

Postby BrianKrebs via Krebs on Security »

KrebsOnSecurity received many a missive over the past 24 hours from readers who wanted to know why I’d not written about widespread media reports that Mirai — a malware strain made from hacked “Internet of Things” (IoT) devices such as poorly secured routers and IP cameras — was used to knock the entire country of Liberia offline. The trouble is, as far as I can tell no such nationwide outage actually occurred.

First, a quick recap on Mirai: This blog was taken offline in September following a record 620 Gpbs attack launched by a Mirai botnet. The source code for Mirai was leaked online at the end of September. Since then, the code has been forked several times, resulting in the emergence of several large Mirai-based botnets. In late October, many of the Internet’s top destinations went offline for the better part of a day when Mirai was used to attack Internet infrastructure firm Dyn.

Enter Kevin Beaumont, a security architect from Liverpool, England who on Thursday published a piece on Medium.com about an attack by Mirai against Liberia. Beaumont had been researching the output of an automated Twitter account set up by security researchers to monitor attacks from these various Mirai botnets. That Twitter account, @MiraiAttacks, burps out a tweet with each new Mirai attack, listing the targeted Internet address, the attack type, and the observed duration of the attack.

Beamont’s story noted that a botnet based on Mirai was seen attacking the telecommunications infrastructure in the West African nation of Liberia. Citing anonymous sources, Beaumont said transit providers confirmed an attack of more than 500 Gpbs targeting Liberia’s lone underseas large-transit Internet cable, which Beaumont said “provides a single point of failure for internet access.”

“From monitoring we can see websites hosted in country going offline during the attacks,” Beaumont wrote. “Additionally, a source in country at a Telco has confirmed to a journalist they are seeing intermittent internet connectivity, at times which directly match the attack. The attacks are extremely worrying because they suggest a Mirai operator who has enough capacity to seriously impact systems in a nation state.”

Not long after Beamont’s story went live, a piece at The Hacker News breathlessly announced that hackers using Mirai had succeeded in knocking Liberia off the Internet. The Hacker News piece includes nifty graphics and images of Liberia’s underseas Internet cables. Soon after, ZDNet picked up the outage angle, as did the BBC and The Guardian and a host of other news outlets.

A graphic The Hacker News used to explain Liberia’s susceptibility to a DDoS attack.
The only problem that I can see with these stories is that there does not appear to have been anything close to a country-wide outage as a result of this Mirai attack.

Daniel Brewer, general manager for the Cable Consortium of Liberia, confirmed that his organization has fielded inquiries from news outlets and other interest groups following multiple media reports of a nationwide outage. But he could not point to the reason.

“Both our ACE submarine cable monitoring systems and servers hosted (locally) in LIXP (Liberia Internet Exchange Point) show no downtime in the last 3 weeks,” Brewer said. “While it is likely that a local operator might have experienced a brief outage, we have no knowledge of a national Internet outage and there are no data to [substantiate] that.”

Yes, multiple sources confirm that Mirai was used to launch an attack exceeding 500 Gbps against a mobile telecom provider in Liberia, but those sources also say the provider in question had a denial-of-service attack mitigation plan in place that kicked into action shortly after the attack began.

This was confirmed in a tweet on Thursday by Dyn. The company said in a separate tweet that routing in Liberia has been stable for days.

Akamai, a company with a global Internet presence and visibility, said it saw a dip in traffic levels from Liberia. Akamai tweeted a graphic Thursday evening that indicated traffic to Liberia was lower than normal as compared to traffic patterns from previous days this week. But there was nothing to indicate a nationwide outage, and the dip in traffic may just as well have to do with the fact that the first Thursday of November in Liberia is Thanksgiving, a public holiday there.

“Neither @dynresearch nor @akamai_soti have data supporting the assertion that Liberia suffered a national outage,” tweeted Dyn’s Doug Madory.

To recap: Did a Mirai botnet attack an infrastructure provider in Liberia? No question. Is the IoT problem bad enough that we have to worry about entire countries being knocked offline? Quite possibly. Was there an outage that knocked the country of Liberia offline this week? I have yet to see the evidence to support that claim.
Top

elfutils: memory allocation failure in allocate_elf (common.h)

Postby ago via agostino's blog »

Description:
elfutils is a set of libraries/utilities to handle ELF objects (drop in replacement for libelf).

During the fuzz of libdwarf, I noticed a memory allocation failure which involves elfutils.
Actually there is a proposed patch on the elfutils mailing list, but nobody commented.
EDIT: The patch has been committed, see below.

The complete ASan output:

# dwarfdump $FILE
==21982==ERROR: AddressSanitizer failed to allocate 0x3401fb3000 (223371538432) bytes of LargeMmapAllocator (error code: 12)
==21982==Process memory map follows:
        0x000000400000-0x0000006bc000   /usr/bin/dwarfdump-asan
        0x0000008bb000-0x0000008c3000   /usr/bin/dwarfdump-asan
        0x0000008c3000-0x000000900000   /usr/bin/dwarfdump-asan
        0x000000900000-0x0000015a4000
        0x00007fff7000-0x00008fff7000
        0x00008fff7000-0x02008fff7000
        0x02008fff7000-0x10007fff8000
        0x600000000000-0x603000000000
        0x603000000000-0x603000010000
        0x603000010000-0x604000000000
        0x604000000000-0x604000010000
        0x604000010000-0x619000000000
        0x619000000000-0x619000020000
        0x619000020000-0x624000000000
        0x624000000000-0x624000020000
        0x624000020000-0x640000000000
        0x640000000000-0x640000003000
        0x7f9f19d00000-0x7f9f19e00000
        0x7f9f19f00000-0x7f9f1a000000
        0x7f9f1a0a9000-0x7f9f1c3fb000
        0x7f9f1c3fb000-0x7f9f1c58e000   /lib64/libc-2.22.so
        0x7f9f1c58e000-0x7f9f1c78e000   /lib64/libc-2.22.so
        0x7f9f1c78e000-0x7f9f1c792000   /lib64/libc-2.22.so
        0x7f9f1c792000-0x7f9f1c794000   /lib64/libc-2.22.so
        0x7f9f1c794000-0x7f9f1c798000
        0x7f9f1c798000-0x7f9f1c7ae000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7f9f1c7ae000-0x7f9f1c9ad000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7f9f1c9ad000-0x7f9f1c9ae000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7f9f1c9ae000-0x7f9f1c9af000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7f9f1c9af000-0x7f9f1c9b1000   /lib64/libdl-2.22.so
        0x7f9f1c9b1000-0x7f9f1cbb1000   /lib64/libdl-2.22.so
        0x7f9f1cbb1000-0x7f9f1cbb2000   /lib64/libdl-2.22.so
        0x7f9f1cbb2000-0x7f9f1cbb3000   /lib64/libdl-2.22.so
        0x7f9f1cbb3000-0x7f9f1ccb0000   /lib64/libm-2.22.so
        0x7f9f1ccb0000-0x7f9f1ceaf000   /lib64/libm-2.22.so
        0x7f9f1ceaf000-0x7f9f1ceb0000   /lib64/libm-2.22.so
        0x7f9f1ceb0000-0x7f9f1ceb1000   /lib64/libm-2.22.so
        0x7f9f1ceb1000-0x7f9f1ceb7000   /lib64/librt-2.22.so
        0x7f9f1ceb7000-0x7f9f1d0b7000   /lib64/librt-2.22.so
        0x7f9f1d0b7000-0x7f9f1d0b8000   /lib64/librt-2.22.so
        0x7f9f1d0b8000-0x7f9f1d0b9000   /lib64/librt-2.22.so
        0x7f9f1d0b9000-0x7f9f1d0d0000   /lib64/libpthread-2.22.so
        0x7f9f1d0d0000-0x7f9f1d2cf000   /lib64/libpthread-2.22.so
        0x7f9f1d2cf000-0x7f9f1d2d0000   /lib64/libpthread-2.22.so
        0x7f9f1d2d0000-0x7f9f1d2d1000   /lib64/libpthread-2.22.so
        0x7f9f1d2d1000-0x7f9f1d2d5000
        0x7f9f1d2d5000-0x7f9f1d2ea000   /lib64/libz.so.1.2.8
        0x7f9f1d2ea000-0x7f9f1d4e9000   /lib64/libz.so.1.2.8
        0x7f9f1d4e9000-0x7f9f1d4ea000   /lib64/libz.so.1.2.8
        0x7f9f1d4ea000-0x7f9f1d4eb000   /lib64/libz.so.1.2.8
        0x7f9f1d4eb000-0x7f9f1d502000   /usr/lib64/libelf-0.166.so
        0x7f9f1d502000-0x7f9f1d702000   /usr/lib64/libelf-0.166.so
        0x7f9f1d702000-0x7f9f1d703000   /usr/lib64/libelf-0.166.so
        0x7f9f1d703000-0x7f9f1d704000   /usr/lib64/libelf-0.166.so
        0x7f9f1d704000-0x7f9f1d726000   /lib64/ld-2.22.so
        0x7f9f1d8b2000-0x7f9f1d91a000
        0x7f9f1d91a000-0x7f9f1d925000
        0x7f9f1d925000-0x7f9f1d926000   /lib64/ld-2.22.so
        0x7f9f1d926000-0x7f9f1d927000   /lib64/ld-2.22.so
        0x7f9f1d927000-0x7f9f1d928000
        0x7ffc7e844000-0x7ffc7e865000   [stack]
        0x7ffc7e905000-0x7ffc7e907000   [vvar]
        0x7ffc7e907000-0x7ffc7e909000   [vdso]
        0xffffffffff600000-0xffffffffff601000   [vsyscall]
==21982==End of process memory map.
==21982==AddressSanitizer CHECK failed: /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:183 "((0 && "unable to mmap")) != (0)" (0x0, 0x0)
    #0 0x4ca3ed in __asan::AsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_rtl.cc:67
    #1 0x4d0f23 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:159
    #2 0x4d1111 in __sanitizer::ReportMmapFailureAndDie(unsigned long, char const*, char const*, int, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:183
    #3 0x4da14a in __sanitizer::MmapOrDie(unsigned long, char const*, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix.cc:122
    #4 0x42493a in __sanitizer::LargeMmapAllocator::Allocate(__sanitizer::AllocatorStats*, unsigned long, unsigned long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1033
    #5 0x42493a in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback>, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> >, __sanitizer::LargeMmapAllocator >::Allocate(__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> >*, unsigned long, unsigned long, bool, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1302
    #6 0x42493a in __asan::Allocator::Allocate(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:368
    #7 0x420003 in __asan::Allocator::Calloc(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:557
    #8 0x420003 in __asan::asan_calloc(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:722
    #9 0x4c0c3a in calloc /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:67
    #10 0x7f9f1d4ee5e0 in allocate_elf /tmp/portage/dev-libs/elfutils-0.166/work/elfutils-0.166/libelf/common.h:74
    #11 0x7f9f1d4ee5e0 in file_read_elf /tmp/portage/dev-libs/elfutils-0.166/work/elfutils-0.166/libelf/elf_begin.c:282
    #12 0x7f9f1d4ef2b8 in read_unmmaped_file /tmp/portage/dev-libs/elfutils-0.166/work/elfutils-0.166/libelf/elf_begin.c:584
    #13 0x7f9f1d4ef2b8 in read_file /tmp/portage/dev-libs/elfutils-0.166/work/elfutils-0.166/libelf/elf_begin.c:670
    #14 0x4f9676 in main /tmp/dwarf-20161021/dwarfdump/dwarfdump.c:585:11
    #15 0x7f9f1c41b61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #16 0x419588 in _start (/usr/bin/dwarfdump-asan+0x419588)
Affected version:
0.166

Fixed version:
N/A

Proposed patch:
https://lists.fedorahosted.org/archives/list/elfutils-devel@lists.fedorahosted.org/message/EJWVY7TMRDEMWPAPNVU3V4MZYG5HANF2/

Commit Fix:
https://git.fedorahosted.org/cgit/elfutils.git/commit/?id=191000fdedba3fafe4d5b8cddad3f3318b49c3fb

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/raw/master/00011-elfutils-memalloc-allocate_elf

Timeline:
2016-10-24: bug discovered and reported to upstream
2016-11-04: blog post about the issue
2016-11-10: upstream committed the proposed patch

Note:
This bug was found with American Fuzzy Lop.

Permalink:

elfutils: memory allocation failure in allocate_elf (common.h)

Top

elfutils: memory allocation failure in __libelf_set_rawdata_wrlock (elf_getdata.c)

Postby ago via agostino's blog »

Description:
elfutils is a set of libraries/utilities to handle ELF objects (drop in replacement for libelf).

During the fuzz of libdwarf, I noticed a memory allocation failure which involves elfutils.
To have a double-check, the bug was first reported to the libdwarf maintainer and then to the elfutils maintainer. Actually there is a proposed patch on the elfutils mailing list, but nobody commented.

The complete ASan output:

# dwarfdump $FILE
==30083==ERROR: AddressSanitizer failed to allocate 0x8000003000 (549755826176) bytes of LargeMmapAllocator (error code: 12)
==30083==Process memory map follows:
	0x000000400000-0x0000006bb000	/usr/bin/dwarfdump-asan
	0x0000008ba000-0x0000008c2000	/usr/bin/dwarfdump-asan
	0x0000008c2000-0x0000008ff000	/usr/bin/dwarfdump-asan
	0x0000008ff000-0x0000015a3000	
	0x00007fff7000-0x00008fff7000	
	0x00008fff7000-0x02008fff7000	
	0x02008fff7000-0x10007fff8000	
	0x600000000000-0x602000000000	
	0x602000000000-0x602000010000	
	0x602000010000-0x603000000000	
	0x603000000000-0x603000010000	
	0x603000010000-0x604000000000	
	0x604000000000-0x604000010000	
	0x604000010000-0x607000000000	
	0x607000000000-0x607000010000	
	0x607000010000-0x611000000000	
	0x611000000000-0x611000010000	
	0x611000010000-0x612000000000	
	0x612000000000-0x612000010000	
	0x612000010000-0x613000000000	
	0x613000000000-0x613000010000	
	0x613000010000-0x614000000000	
	0x614000000000-0x614000020000	
	0x614000020000-0x619000000000	
	0x619000000000-0x619000020000	
	0x619000020000-0x61c000000000	
	0x61c000000000-0x61c000020000	
	0x61c000020000-0x61d000000000	
	0x61d000000000-0x61d000020000	
	0x61d000020000-0x624000000000	
	0x624000000000-0x624000020000	
	0x624000020000-0x625000000000	
	0x625000000000-0x625000020000	
	0x625000020000-0x640000000000	
	0x640000000000-0x640000003000	
	0x7f0afdc00000-0x7f0afdd00000	
	0x7f0afde00000-0x7f0afdf00000	
	0x7f0afdff0000-0x7f0b00342000	
	0x7f0b00342000-0x7f0b004d5000	/lib64/libc-2.22.so
	0x7f0b004d5000-0x7f0b006d5000	/lib64/libc-2.22.so
	0x7f0b006d5000-0x7f0b006d9000	/lib64/libc-2.22.so
	0x7f0b006d9000-0x7f0b006db000	/lib64/libc-2.22.so
	0x7f0b006db000-0x7f0b006df000	
	0x7f0b006df000-0x7f0b006f5000	/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
	0x7f0b006f5000-0x7f0b008f4000	/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
	0x7f0b008f4000-0x7f0b008f5000	/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
	0x7f0b008f5000-0x7f0b008f6000	/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
	0x7f0b008f6000-0x7f0b008f8000	/lib64/libdl-2.22.so
	0x7f0b008f8000-0x7f0b00af8000	/lib64/libdl-2.22.so
	0x7f0b00af8000-0x7f0b00af9000	/lib64/libdl-2.22.so
	0x7f0b00af9000-0x7f0b00afa000	/lib64/libdl-2.22.so
	0x7f0b00afa000-0x7f0b00bf7000	/lib64/libm-2.22.so
	0x7f0b00bf7000-0x7f0b00df6000	/lib64/libm-2.22.so
	0x7f0b00df6000-0x7f0b00df7000	/lib64/libm-2.22.so
	0x7f0b00df7000-0x7f0b00df8000	/lib64/libm-2.22.so
	0x7f0b00df8000-0x7f0b00dfe000	/lib64/librt-2.22.so
	0x7f0b00dfe000-0x7f0b00ffe000	/lib64/librt-2.22.so
	0x7f0b00ffe000-0x7f0b00fff000	/lib64/librt-2.22.so
	0x7f0b00fff000-0x7f0b01000000	/lib64/librt-2.22.so
	0x7f0b01000000-0x7f0b01017000	/lib64/libpthread-2.22.so
	0x7f0b01017000-0x7f0b01216000	/lib64/libpthread-2.22.so
	0x7f0b01216000-0x7f0b01217000	/lib64/libpthread-2.22.so
	0x7f0b01217000-0x7f0b01218000	/lib64/libpthread-2.22.so
	0x7f0b01218000-0x7f0b0121c000	
	0x7f0b0121c000-0x7f0b01231000	/lib64/libz.so.1.2.8
	0x7f0b01231000-0x7f0b01430000	/lib64/libz.so.1.2.8
	0x7f0b01430000-0x7f0b01431000	/lib64/libz.so.1.2.8
	0x7f0b01431000-0x7f0b01432000	/lib64/libz.so.1.2.8
	0x7f0b01432000-0x7f0b01449000	/usr/lib64/libelf-0.166.so
	0x7f0b01449000-0x7f0b01649000	/usr/lib64/libelf-0.166.so
	0x7f0b01649000-0x7f0b0164a000	/usr/lib64/libelf-0.166.so
	0x7f0b0164a000-0x7f0b0164b000	/usr/lib64/libelf-0.166.so
	0x7f0b0164b000-0x7f0b0166d000	/lib64/ld-2.22.so
	0x7f0b017f7000-0x7f0b01860000	
	0x7f0b01860000-0x7f0b0186c000	
	0x7f0b0186c000-0x7f0b0186d000	/lib64/ld-2.22.so
	0x7f0b0186d000-0x7f0b0186e000	/lib64/ld-2.22.so
	0x7f0b0186e000-0x7f0b0186f000	
	0x7ffff2f19000-0x7ffff2f3a000	[stack]
	0x7ffff2f3d000-0x7ffff2f3f000	[vvar]
	0x7ffff2f3f000-0x7ffff2f41000	[vdso]
	0xffffffffff600000-0xffffffffff601000	[vsyscall]
==30083==End of process memory map.
==30083==AddressSanitizer CHECK failed: /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:183 "((0 && "unable to mmap")) != (0)" (0x0, 0x0)
    #0 0x4ca3ed in __asan::AsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_rtl.cc:67
    #1 0x4d0f23 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:159
    #2 0x4d1111 in __sanitizer::ReportMmapFailureAndDie(unsigned long, char const*, char const*, int, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:183
    #3 0x4da14a in __sanitizer::MmapOrDie(unsigned long, char const*, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix.cc:122
    #4 0x4224df in __sanitizer::LargeMmapAllocator::Allocate(__sanitizer::AllocatorStats*, unsigned long, unsigned long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1033
    #5 0x4224df in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback>, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> >, __sanitizer::LargeMmapAllocator >::Allocate(__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> >*, unsigned long, unsigned long, bool, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1302
    #6 0x4224df in __asan::Allocator::Allocate(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:368
    #7 0x4224df in __asan::asan_malloc(unsigned long, __sanitizer::BufferedStackTrace*) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:718
    #8 0x4c0ab1 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:53
    #9 0x7f0b0143c206 in __libelf_set_rawdata_wrlock /tmp/portage/dev-libs/elfutils-0.166/work/elfutils-0.166/libelf/elf_getdata.c:318
    #10 0x7f0b0143c5db in __elf_getdata_rdlock /tmp/portage/dev-libs/elfutils-0.166/work/elfutils-0.166/libelf/elf_getdata.c:521
    #11 0x580659 in dwarf_elf_object_access_load_section /tmp/dwarf-20161001/libdwarf/dwarf_elf_access.c:1312:16
    #12 0x5b5142 in _dwarf_load_section /tmp/dwarf-20161001/libdwarf/dwarf_init_finish.c:1139:11
    #13 0x6082ae in _dwarf_load_debug_info /tmp/dwarf-20161001/libdwarf/dwarf_util.c:855:11
    #14 0x57043f in _dwarf_next_cu_header_internal /tmp/dwarf-20161001/libdwarf/dwarf_die_deliv.c:819:32
    #15 0x572fcd in dwarf_next_cu_header_d /tmp/dwarf-20161001/libdwarf/dwarf_die_deliv.c:629:15
    #16 0x512f4f in print_one_die_section /tmp/dwarf-20161001/dwarfdump/print_die.c:660:16
    #17 0x512262 in print_infos /tmp/dwarf-20161001/dwarfdump/print_die.c:371:16
    #18 0x4faaea in process_one_file /tmp/dwarf-20161001/dwarfdump/dwarfdump.c:1371:9
    #19 0x4faaea in main /tmp/dwarf-20161001/dwarfdump/dwarfdump.c:654
    #20 0x7f0b0036261f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #21 0x419588 in _start (/usr/bin/dwarfdump-asan+0x419588)
Affected version:
0.166

Fixed version:
N/A

Proposed patch:
https://lists.fedorahosted.org/archives/list/elfutils-devel@lists.fedorahosted.org/thread/Q4LE47FPEVRZANMV6JE2NMHYO4H5MHGJ/

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00031-elfutils-memalloc-__libelf_set_rawdata_wrlock

Timeline:
2016-10-03: bug discovered
2016-10-21: bug reported to upstream
2016-11-04: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

elfutils: memory allocation failure in __libelf_set_rawdata_wrlock (elf_getdata.c)

Top

Ne’er-Do-Well News and Cyber Justice

Postby BrianKrebs via Krebs on Security »

Way back in the last millennium when I was a lowly copy aide at The Washington Post, I pitched the Metro Section editor on an idea for new column: “And the Good News Is…” The editor laughed me out of her office. But I still think it’s a decent idea — particularly in the context of cybersecurity — to periodically highlight the good news when people allegedly responsible for spewing so much badness online are made to face justice.

NCA officials lead away a suspect arrested in this week’s raids. Image: NCA.
In the United Kingdom this week, 14 people were arrested on suspicion of laundering at least £11 million (~USD $13.7M) on behalf of thieves who stole the money using sophisticated banking Trojans like Dridex and Dyre. A statement issued by the U.K.’s National Crime Agency (NCA) said 13 men and a woman, aged between 23 and 52, were arrested in the roundup, including a number of foreign nationals.

The NCA warned in a report released this year that cybercrime had overtaken traditional crime in the United Kingdom. According to the U.K.’s Office of National Statistics, there were 2.46 million cyber incidents and 2.11 million victims of cybercrime in the U.K. in 2015.

Also in the U.K., 19-year-old Adam Mudd pleaded guilty to operating and profiting from Titanium Stresser, an attack-for-hire or “booter” service that could be hired to knock Web sites offline. When U.K. authorities arrested Mudd at his home last year, they found detailed records of the attack service’s customers and victims, which included evidence of more than 1.7 million attacks. Prosecutors say Mudd launched the service when he was 15 years old.

TitaniumStresser[dot]net, as it appeared in 2014.
As I noted in this 2014 story, the source code for Titanium Stresser was later used by miscreants with the Lizard Squad hacking group to power their Lizard Stresser attack service. Happily, two other 19-year-olds were arrested earlier this month and accused of operating the Lizard Stresser attack service. It’s nice to see authorities here and abroad sending a message that operating booter service can land you in jail, full stop.

Back stateside, a Florida man has pleaded guilty to hacking and spamming the world with ads for online pharmacies and other businesses eager to buy dodgy customer leads. Timothy Livingston, 31, acknowledged that he and his company — aptly named “A Whole Lot of Nothing LLC” — earned more than $1.3 million using countless hacked email accounts and huge collections of compromised computers to relay the junk missives.

Livingston could hardly be a better caricature of the typical spammer. Living in Florida (Boca Raton) and lavishly spending his ill-gotten gains on a flashy lifestyle. As part of his plea, Livingston agreed to forfeit $1,346,442, as well as a 2009 Cadillac Escalade and a 2006 Ferrari F430 Spider.

A 2006 Ferrari F430 Spider. Image: Flickr, via Davocano.
Top

jasper: use of uninitialized value in jpc_pi_nextcprl (jpc_t2cod.c)

Postby ago via agostino's blog »

Description:
jasper is an open-source initiative to provide a free software-based reference implementation of the codec specified in the JPEG-2000 Part-1 standard.

I decided to try another round of fuzzing with the Memory Sanitizer enabled, and I discovered that there is an use-of-uninitialized-value in jpc_pi_nextcprl

The complete MSan output:

# imginfo -f $FILE
warning: trailing garbage in marker segment (14 bytes)                                                                                                                                                                                                                         
warning: trailing garbage in marker segment (14 bytes)                                                                                                                                                                                                                         
warning: ignoring unknown marker segment                                                                                                                                                                                                                                       
type = 0xff41 (UNKNOWN); len = 20;01 87 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 warning: trailing garbage in marker segment (14 bytes)                                                                                                                                 
==7937==WARNING: MemorySanitizer: use-of-uninitialized-value                                                                                                                                                                                                                   
    #0 0x7fc562323907 in jpc_pi_nextcprl /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_t2cod.c:482:12                                                                                                                                     
    #1 0x7fc562323907 in jpc_pi_next /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_t2cod.c:125                                                                                                                                            
    #2 0x7fc56232aadc in jpc_dec_decodepkts /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_t2dec.c:441:14                                                                                                                                  
    #3 0x7fc5621fa9f1 in jpc_dec_process_sod /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_dec.c:594:6                                                                                                                                    
    #4 0x7fc56220c574 in jpc_dec_decode /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_dec.c:391:10                                                                                                                                        
    #5 0x7fc56220c574 in jpc_decode /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_dec.c:255                                                                                                                                               
    #6 0x7fc5621ac5a4 in jp2_decode /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jp2/jp2_dec.c:215:21                                                                                                                                            
    #7 0x7fc5620d69d1 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/base/jas_image.c:396:16                                                                                                                                   
    #8 0x557bb7618831 in main /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/appl/imginfo.c:203:16                                                                                                                                                           
    #9 0x7fc5611e961f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                                                                                                        
    #10 0x557bb7599a28 in _init (/usr/bin/imginfo+0x1aa28)                                                                                                                                                                                                                     
                                                                                                                                                                                                                                                                               
  Uninitialized value was created by a heap allocation                                                                                                                                                                                                                         
    #0 0x557bb75bf639 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/msan/msan_interceptors.cc:1002                                                                                                                           
    #1 0x7fc5621507d4 in jas_malloc /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/base/jas_malloc.c:148:13                                                                                                                                        
    #2 0x7fc562152520 in jas_alloc2 /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/base/jas_malloc.c:275:9                                                                                                                                         
    #3 0x7fc56233360c in jpc_dec_pi_create /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_t2dec.c:506:30                                                                                                                                   
    #4 0x7fc5621f2c71 in jpc_dec_tileinit /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_dec.c:911:19                                                                                                                                      
    #5 0x7fc5621f2c71 in jpc_dec_process_sod /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_dec.c:560                                                                                                                                      
    #6 0x7fc56220c574 in jpc_dec_decode /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_dec.c:391:10                                                                                                                                        
    #7 0x7fc56220c574 in jpc_decode /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_dec.c:255                                                                                                                                               
    #8 0x7fc5621ac5a4 in jp2_decode /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jp2/jp2_dec.c:215:21                                                                                                                                            
    #9 0x7fc5620d69d1 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/base/jas_image.c:396:16                                                                                                                                   
    #10 0x557bb7618831 in main /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/appl/imginfo.c:203:16                                                                                                                                                          
    #11 0x7fc5611e961f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                                                                                                       
                                                                                                                                                                                                                                                                               
SUMMARY: MemorySanitizer: use-of-uninitialized-value /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/jpc/jpc_t2cod.c:482:12 in jpc_pi_nextcprl                                                                                                      
Exiting
Affected version:
1.900.17

Fixed version:
1.900.20

Commit fix:
https://github.com/mdadams/jasper/commit/1f0dfe5a42911b6880a1445f13f6d615ddb55387

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00029-jasper-uninitvalue-jpc_pi_nextcprl

Timeline:
2016-11-03: bug discovered and reported to upstream
2016-11-04: upstream released a patch
2016-11-04: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

jasper: use of uninitialized value in jpc_pi_nextcprl (jpc_t2cod.c)

Top

2015 Syncopation red blend and Acoustic white blend from Mike Ward on Wine

Postby Zach via The Z-Issue »

At the end of August—I know that it’s now November, but time seems to get away from me more often these days—I got the honour of trying the new 2015 vintage of Syncopation red blend (read about the 2014 vintage here) from Mike Ward on Wine! This is the second year that Mike has produced the incredible blend that changed my perspective on Missouri wines, and this year, it was joined by the new Acoustic white blend. Before getting into the new white blend, let’s take a look at the changes for this 2015 release of Syncopation Rhythmic red blend.

Unlike the 2014 vintage—which was a blend of Chambourcin, Vidal blanc, Seyval blanc, and Traminette—this year was a cuvée of Chambourcin, Vignoles, Norton, and Traminette. So, the primary varietal is still Chambourcin, and the Traminette remains (though is slightly more prominent than last year). The Vidal blanc and Seyval blanc, though, were replaced by Vignoles and Norton. The breakdown in varietals is 70% Chambourcin, and 10% of the remaining three grapes.

Seeing as the Vidal blanc and Seyval blanc, which are both white grapes, were replaced by Vignoles (a complex hybrid) and Norton (a very deep purple grape, somewhat resembling Concords), I didn’t really have any idea what to expect from this new blend. Below are my impressions:

2015 Syncopation Rhythmic Red blend – tasting notes:
With its beautiful ruby-to-garnet colour, this wine shows wonderfully when backlit in the glass. Subdued purples shine through the burgundy in the centre, and it is encompassed by a dark pink ring at the edges. A bouquet of red plum and blueberries is evident, but completely unassuming and lovely in its simplicity. Interestingly, though, those fruits didn’t come through for me in taste. Instead, I found raspberry, strawberry, and forest underbrush (akin to some Pinot noirs from Oregon’s Willamette Valley) to be much more prominent on the palate. Those flavours were further complimented by slight hints of clove and white pepper. Fascinatingly, though this is not a sparkling wine in any way, there was a slight effervescent feel upfront. Like the previous vintage, I found that this Syncopation red blend is best enjoyed with a slight chill on it (14-16°C / 57-61°F).


Mike and his 2015 Syncopation wines

Syncopation Rhythmic Red
I was quite confident that I would enjoy this new vintage of Syncopation red, but I wasn’t sure how I would feel about the new Acoustic white blend since this year was its debut. Once again, Mike Ward challenged what I thought I knew about my taste preferences by creating an absolutely outstanding white wine that is sure to please a wide array of tastes! Syncopation Acoustic White is a blend of 70% Vignoles, 20% Vidal Blanc, and 10% Traminette.

2015 Syncopation Acoustic White blend – tasting notes:
A light but vivid yellow in the glass, this brilliant blend demands your attention due to its dazzling vibrancy! On the nose, there is an elegant mix of less pronounced, almost musky fruits like apricot and the mellow sweetness of Bosc pears. There is an ever-so-faint hint of ginger and lemon zest that adds to the wine’s elusive profile. It has a crisp yet completely approachable acidity. The lemon starts to come through, but is almost immediately thwarted off by the more rounded flavours of nectarine and apricot.

Overall, I enjoyed both of these wines, chiefly seeing as Missouri wines are not usually my favourites. Having tasted the 2014 and 2015 Syncopation Rhythmic Red blends side-by-side, I slightly prefer the 2014. That could be caused by any number of factors, but I am willing to bet that it is due to my strong preference for Vidal blanc. Changing out two white grapes (the Vidal blanc and Seyval blanc) for another red grape (the Norton) significantly changed the flavour profile, especially given the almost mordant forwardness of big fruits exhibited by Norton. We are splitting hairs here though, because both years have shown me the intricacies that Missouri wines are capable of producing. Further, I was taken aback by the Acoustic White blend, and find it to rank amongst my favourites of Missouri whites. I am sure that I will enjoy many bottles of these two wines over the upcoming year, and am excited to experience the next incantation of Mike Ward’s Syncopation!

So, I encourage you to pick up at least a bottle of each and experience them for yourself—even if you were like me in thinking that Missouri wines didn’t hold their own. You can purchase them at several Saint Louis area Schnucks grocery stores, or by stopping in at The Wine Barrel on Lindbergh near Watson. At The Wine Barrel, you can also choose to try Syncopation by the glass, and if you’re lucky, Mike may even be there when you stop by.

Cheers,
Zach
Top

Flashing an LSI SAS 9201-16i

Postby Dan Langille via Dan Langille's Other Diary »

WARNING: This did not work. It succeeded, without error, but the card did not work. There will be a new blog post soon. Yesterday, a new LSI SAS 9201-16i arrived. I bought it on eBay from a supplier in China and paid for expedited shipping. I offered US$250 for their $338 listing and it was [...]
Top