Planet

‘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-r1
sys-kernel/gentoo-sources-4.1.36-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.
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

Computer Virus Cripples UK Hospital System

Postby BrianKrebs via Krebs on Security »

Citing a computer virus outbreak, a hospital system in the United Kingdom has canceled all planned operations and diverted major trauma cases to neighboring facilities. The incident came as U.K. leaders detailed a national cyber security strategy that promises billions in cybersecurity spending, new special police units to pursue organized online gangs, and the possibility of retaliation for major attacks.

In a “major incident” alert posted to its Web site, the National Health Service’s Lincolnshire and Goole trust said it made the decision to cancel surgeries and divert trauma patients after a virus infected its electronic systems on Sunday, October 30.

A portion of the alert posted to the NHS’s home page.
“We have taken the decision, following expert advise, to shut down the majority of our systems so we can isolate and destroy it,” the NHS said, of the unspecified malware infection. “All planned operations, outpatient appointments and diagnostic procedures have been cancelled for Wednesday, Nov. 2 with a small number of exceptions.”

The advisory continued:

“Inpatients will continue to be cared for and discharged as soon as they are medically fit. Major trauma cases will continue to be diverted to neighboring hospitals as will high risk women in labour.”

Although the NHS didn’t say what kind of virus infected its systems, it is likely an infestation of ransomware — a malware scourge whose purveyors have taken to targeting hospitals and healthcare facilities.

Ransomware scours an infected computer for documents, audio files, pictures and other things likely to be of value to the system’s owner, and then encrypts that data with very powerful encryption software. Most ransomware variants also scour the local network for other systems or network shares to infect. Victims usually can only get their files back after paying a specified ransom demand using a virtual currency, such as Bitcoin.

Earlier this year, experts began noticing that cybercriminals were using ransomware to target hospitals — organizations that are heavily reliant on instant access to patient records. In March 2016, Henderson, Ky.-based Methodist Hospital shut down its computer systems after an infection from the Locky strain of ransomware. Just weeks before that attack, a California hospital that was similarly besieged with ransomware paid a $17,000 ransom to get its files back.

According to a recent report by Intel Security, the healthcare sector is experiencing over 20 data loss incidents per day related to ransomware attacks. The company said it identified almost $100,000 in payments from hospital ransomware victims to specific bitcoin accounts so far in 2016.

As dependent as healthcare systems are on computers and information technology, the notion that a computer virus could result in bodily injury or death is no longer the stuff of Hollywood movie scripts. Unfortunately, the healthcare industry is for the most part still catching up in its ability to anticipate, prevent and respond to these types of cyber attacks.

As macabre as it may sound, perhaps people dying because of poor cybersecurity is exactly what it will take for more organizations to dedicate the necessary resources toward adequately defending the systems upon which they so heavily rely.

In 2010, I was interviewed by Team Cyrmu‘s Steve Santorelli as part of their ongoing Who and Why Show. Santorelli gave me a few minutes to answer the question, “What keeps you up at night?” My answer was basically that I worry what will happen to the Internet as we know it when people start to die in a measurable way because of computer and Internet security vulnerabilities and attacks. Here’s the entire interview if anyone cares to have a listen.

The crippling of NHS’s systems came as U.K. Chancellor Philip Hammond unveiled a national cybersecurity strategy, warning that hostile “foreign actors” were developing techniques that threaten the country’s electrical grid and airports, among other critical infrastructure.

“If we want Britain to be the best place in the world to be a tech business then it is also crucial that Britain is a safe place to do the digital business,” Hammond said Tuesday as he described the National Cyber Security Strategy in London. “Trust in the internet and the infrastructure on which it relies is fundamental to our economic future.”

What can businesses do to lessen the chances of having their critical infrastructure crippled by malware like ransomware? The FBI has the following tips:

  • Regularly back up data and verify the integrity of those backups. Backups are critical in ransomware incidents; if you are infected, backups may be the best way to recover your critical data.
  • Secure your backups. Ensure 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, some instances of ransomware have the capability to lock cloud-based backups when systems continuously back up in real-time, also known as persistent synchronization.
  • Scrutinize links contained in e-mails and do not open attachments included in unsolicited e-mails.
  • Only download software – especially free software – from sites you know and trust. When possible, verify the integrity of the software through a digital signature prior to execution.
  • Ensure application patches for the operating system, software, and firmware are up to date, including Adobe Flash, Java, Web browsers, etc.
  • Ensure anti-virus and anti-malware solutions are set to automatically update and regular scans are conducted.
  • Disable macro scripts from files transmitted via e-mail. Consider using Office Viewer software to open Microsoft Office files transmitted via e-mail instead of full Office Suite applications.
  • Implement software restrictions or other controls to prevent the execution of programs in common ransomware locations, such as temporary folders supporting popular Internet browsers, or compression/decompression programs, including those located in the AppData/LocalAppData folder.
Additional considerations for businesses include the following:

  • Focus on awareness and training. Because end users are often targeted, employees should be made aware of the threat of ransomware, how it is delivered, and trained on information security principles and techniques.
  • Patch all endpoint device operating systems, software, and firmware as vulnerabilities are discovered. This precaution can be made easier through a centralized patch management system.
  • Manage the use of privileged accounts by implementing the principle of least privilege. No users should be assigned administrative access unless absolutely needed. Those with a need for administrator accounts should only use them when necessary; they should operate with standard user accounts at all other times.
  • Configure access controls with least privilege in mind. If a user only needs to read specific files, he or she should not have write access to those files, directories, or shares.
  • Use virtualized environments to execute operating system environments or specific programs.
  • Categorize data based on organizational value, and implement physical/logical separation of networks and data for different organizational units. For example, sensitive research or business data should not reside on the same server and/or network segment as an organization’s e-mail environment.
  • Require user interaction for end user applications communicating with Web sites uncategorized by the network proxy or firewall. Examples include requiring users to type in information or enter a password when the system communicates with an uncategorized Web site.
  • Implement application whitelisting. Only allow systems to execute programs known and permitted by security policy.
Further reading: SC Magazine UK’s take on the attack.
Top

This week in vc4 (2016-10-31): HDMI audio

Postby Eric Anholt via anholt's lj »

Last week was spent almost entirely on HDMI audio support.

I had started the VC4-side HDMI setup last week, and got the rest of the stubbed bits filled out this week.

Next was starting to get the audio side connected.  I had originally derived my VC4 side from the Mediatek driver, which makes a child device for the generic "hdmi-codec" DAI codec to attach to.  HDMI-codec is a shared implementation for HDMI encoders that take I2S input, which basically just passes audio setup params into the DRM HDMI encoder, whose job is to actually make I2S signals on wires get routed into HDMI audio packets.  They also have a CPU DAI registered through device tree that moves PCM data from memory onto wires, and a machine driver registered through devicetree that connects the CPU DAI's wires to the HDMI codec DAI's wires.  This is apparently how SoC audio is usually structured.

VC4, on the other hand, doesn't have a separate hardware block for moving PCM data from memory onto wires, it just has the MAI_DATA register in the HDMI block that you put S/PDIF (IEC958) data into using the SoC's generic DMA engine.  So I made VC4's HDMI driver register another a child device with the MAI_DATA register's address passed in, and that child device gets bound by the CPU DAI driver and uses the ASoC generic DMA engine support.  That CPU DAI driver also ends up setting up the machine driver, since I didn't have any other reference to the CPU DAI anywhere.  The glue here is all based on static strings I can't rely on, and is a complete hack for now.

Last, notice how I've used "PCM" talking about a working implementation's audio data and "S/PDIF" data for the thing I have to take in?  That's the sticking point.  The MAI_DATA register wants things that look like the AES3 frames description you can find on wikipedia.  I think the HW is generating my preamble.  In the firmware's HDMI audio implementation, they go through the unpacked PCM data and set the channel status bit in each sample according to the S/PDIF channel status word (the first 2 bytes of which are also documented on wikipedia).   At the same time that they're doing that, they also set the parity bit.

My first thought was "Hey, look, ALSA has SNDRV_PCM_FORMAT_IEC958_SUBFRAME, maybe my codec can say it only takes these S/PDIF frames and everything will work out."  No.  It turns out aplay won't generate them and neither will gstreamer.  To make a usable HDMI audio driver, I'm going to need to generate my IEC958 myself.

Linux is happy to generate my channel status word in memory.  I think the hardware is happy to generate my parity bit.  That just leaves making the CPU DAI write the bits of the channel status word into the subframes as PCM samples come in to the driver, and making sure that the MSB of the PCM audio data is bit 27.  I haven't figured out how to do that quite yet, which is the project for this week.

Work-in-progress, completely non-functional code is here.
Top

Hackforums Shutters Booter Service Bazaar

Postby BrianKrebs via Krebs on Security »

Perhaps the most bustling marketplace on the Internet where people can compare and purchase so-called “booter” and “stresser” subscriptions — attack-for-hire services designed to knock Web sites offline — announced last week that it has permanently banned the sale and advertising of these services.

On Friday, Oct. 28, Jesse LaBrocca — the administrator of the popular English-language hacking forum Hackforums[dot]net — said he was shutting down the “server stress testing” (SST) section of the forum. The move comes amid heightened public scrutiny of the SST industry, which has been linked to several unusually powerful recent attacks and is responsible for the vast majority of denial-of-service (DOS) attacks on the Internet today.

The administrator of Hackforums bans the sale and advertising of server stress testing (SST) services, also known as “booter” or “stresser” online attack-for-hire services.
“Unfortunately once again the few ruin it for the many,” LaBrocca wrote under his Hackforums alias “Omniscient.” “I’m personally disappointed that this is the path I have to take in order to protect the community. I loathe having to censor material that could be beneficial to members. But I need to make sure that we continue to exist and given the recent events I think it’s more important that the section be permanently shut down.”

Last month, a record-sized DDoS hit KrebsOnSecurity.com. The attack was launched with the help of Mirai, a malware strain that enslaves poorly secured Internet-of-Things (IoT) devices like CCTV cameras and digital video recorders and uses them to launch crippling attacks.

At the end of September, a Hackforums user named “Anna_Senpai” used the forum to announce the release the source code for Mirai. A week ago, someone used Mirai to launch a massive attack on Internet infrastructure firm Dyn, which for the better part of a day lead to sporadic outages for some of the Web’s top destinations, including Twitter, PayPal, Reddit and Netflix.

The Hackforums post that includes links to the Mirai source code.
As I noted in last week’s story Are the Days of Booter Services Numbered?, many booter service owners have been operating under the delusion or rationalization that their services are intended solely for Web site owners to test the ability of their sites to withstand data deluges.

Whatever illusions booter service operators or users may have harbored about their activities should have been dispelled following a talk delivered at the Black Hat security conference in Las Vegas this year. In that speech, FBI Agent Elliott Peterson issued an unambiguous warning that the agency was prepared to investigate and help prosecute people engaged in selling and buying from booter services.

But it wasn’t until this month’s attack on Dyn that LaBrocca warned the Hackforums community he may have to shut down the SST section.

“I can’t image this attention is going to be a good thing,” Omni said in an October 26, 2016 thread titled “Bad things.” “Already a Senator is calling for a hearing on the Internet of Things [link added]. In the end there could be new laws which effect [sic] us all. So for those responsible for the attacks and creating this mess….you dun goofed. I expect a lot of backlash to come out of this.”

If LaBrocca appears steamed from this turn of events, it’s probably with good reason: He stands to lose a fair amount of regular income by banning some of the most lucrative businesses on his forum. Vendors on Hackforums pay fees as high as $25 apiece to achieve a status that allows them to post new sales threads, and banner ads on the forum can run up to $200 per week.

“Stickies” advertising various “booter” or “stresser” DDoS-for-hire services.
Vendors who wish to “sticky” their ads — that is, pay to keep the ads displayed prominently near or at the top of a given discussion subforum — pay LaBrocca up to $60 per week for the prime sticky spots. And there were dozens of booter services advertised on Hackforums.

Allison Nixon, director of security research at Flashpoint and an expert on booter services, said the move could put many booter services out of business.

Nixon said the average booter service customer uses the attack services to settle grudges with opponents in online games, and that the closure of the SST subforum may make these services less attractive to those individuals.

“There is probably a lesser likelihood that the average gamer will see these services and think that it’s an okay idea to purchase them,” Nixon said. “The ease of access to these booters services makes people think it’s okay to use them. In gaming circles, for example, people will often use them to DDoS one another and not realize they might be shutting down an innocent person’s network. Recognizing that this is criminal activity on the same level of criminal hacking and fraud may discourage people from using these services, meaning the casual actor may be less likely to buy a booter subscription and launch DDoS attacks.”

While a welcome development, the closure of the SST subforum almost seems somewhat arbitrary given the sheer amount of other illegal hacking activity that is blatantly advertised on Hackforums, Nixon said.

“It’s interesting the norms that are on this forum because they’re so different from how you or I would recognize acceptable behavior,” she said. “For example, most people would think it’s not acceptable to see booter services advertised alongside remote access Trojans, malware crypting services and botnets.”

Other questionable services and subsections advertised on Hackforums include those intended for the sale of hacked social media and e-commerce accounts. More shocking are the dozens of threads wherein Hackforums members advertise the sale of “girl slaves,” essentially access to hacked computers belonging to teenage girls who can be extorted and exploited for payment or naked pictures. It’s worth noting that the youth who was arrested for snapping nude pictures of Miss Teen USA Cassidy Wolf through her webcam was a regular user of Hackforums.

Hackforums users advertising the sale and procurement of “girl slaves.”
Nixon said most Hackforums users are essentially good people who are interested in learning more about technology, security and other topics. But she said many of the younger, impressionable members are heavily influenced by some of the more senior forum participants, a number of whom are peddling dangerous products and services.

“Most of the stuff on Hackforums is not that bad,” Nixon said. “There are a lot of kids who are pretty much normal people and interested in hacking and technology. But there are also gangs, and there are definitely criminal organizations that have a presence on the forum that will try to enable criminal activity and take advantage of people.”

The removal of booter services from Hackforums is a gratifying development for me personally and professionally. My site has been under near-constant attack from users of these booter services for several years now. As a result, I have sought to bring more public attention to these crooked businesses and to the young men who’ve earned handsome profits operating over the years. Here are just a few of those stories:

Stress Testing the Booter Services, Financially

Are the Days of Booter Services Numbered?

Israeli Online Attack Service ‘vDOS’ Earned $600,000 in Two Years

Ragebooter: Legit DDoS Service, or Fed Backdoor?

DDoS Services Advertise Openly, Take PayPal

Booter Shells Turn Web Sites Into Weapons

Spreading the DDoS Disease and Selling the Cure

Lizard Stresser Runs on Hacked Home Routers

The New Normal: 200-400 Gpbs DDoS Attacks
Top

Intel MediaSDK mini-walkthrough

Postby lu_zero via Luca Barbato »

Using hwaccel

Had been a while since I mentioned the topic and we made a huge progress on this field.

Currently with Libav12 we already have nice support for multiple different hardware support for decoding, scaling, deinterlacing and encoding.

The whole thing works nicely but it isn’t foolproof yet so I’ll start describing how to setup and use it for some common tasks.

This post will be about Intel MediaSDK, the next post will be about NVIDIA Video Codec SDK.

Setup

Prerequisites
  • A machine with QSV hardware, Haswell, Skylake or better.
  • The ability to compile your own kernel and modules
  • The MediaSDK mfx_dispatch
It works nicely both on Linux and Windows. If you happen to have other platforms feel free to contact Intel and let them know, they’ll be delighted.

Installation
The MediaSDK comes with either the usual Windows setup binary or a Linux bash script that tries its best to install the prerequisites.

# tar -xvf MediaServerStudioEssentials2017.tar.gz
MediaServerStudioEssentials2017/
MediaServerStudioEssentials2017/Intel(R)_Media_Server_Studio_EULA.pdf
MediaServerStudioEssentials2017/MediaSamples_Linux_2017.tar.gz
MediaServerStudioEssentials2017/intel_sdk_for_opencl_2016_6.2.0.1760_x64.tgz
MediaServerStudioEssentials2017/site_license_materials.txt
MediaServerStudioEssentials2017/third_party_programs.txt
MediaServerStudioEssentials2017/redist.txt
MediaServerStudioEssentials2017/FEI2017-16.5.tar.gz
MediaServerStudioEssentials2017/SDK2017Production16.5.tar.gz
MediaServerStudioEssentials2017/media_server_studio_essentials_release_notes.pdf
Focus on SDK2017Production16.5.tar.gz.

tar -xvf SDK2017Production16.5.tar.gz
SDK2017Production16.5/
SDK2017Production16.5/Generic/
SDK2017Production16.5/Generic/intel-opencl-16.5-55964.x86_64.tar.xz.sig
SDK2017Production16.5/Generic/intel-opencl-devel-16.5-55964.x86_64.tar.xz.sig
SDK2017Production16.5/Generic/intel-opencl-devel-16.5-55964.x86_64.tar.xz
SDK2017Production16.5/Generic/intel-linux-media_generic_16.5-55964_64bit.tar.gz
SDK2017Production16.5/Generic/intel-opencl-16.5-55964.x86_64.tar.xz
SDK2017Production16.5/Generic/vpg_ocl_linux_rpmdeb.public
SDK2017Production16.5/media_server_studio_getting_started_guide.pdf
SDK2017Production16.5/intel-opencl-16.5-release-notes.pdf
SDK2017Production16.5/intel-opencl-16.5-installation.pdf
SDK2017Production16.5/CentOS/
SDK2017Production16.5/CentOS/libva-1.67.0.pre1-55964.el7.x86_64.rpm
SDK2017Production16.5/CentOS/libdrm-devel-2.4.66-55964.el7.x86_64.rpm
SDK2017Production16.5/CentOS/intel-linux-media-devel-16.5-55964.el7.x86_64.rpm
SDK2017Production16.5/CentOS/intel-i915-firmware-16.5-55964.el7.x86_64.rpm
SDK2017Production16.5/CentOS/install_scripts_centos_16.5-55964.tar.gz
SDK2017Production16.5/CentOS/intel-opencl-devel-16.5-55964.x86_64.rpm
SDK2017Production16.5/CentOS/ukmd-kmod-16.5-55964.el7.src.rpm
SDK2017Production16.5/CentOS/libdrm-2.4.66-55964.el7.x86_64.rpm
SDK2017Production16.5/CentOS/libva-utils-1.67.0.pre1-55964.el7.x86_64.rpm
SDK2017Production16.5/CentOS/intel-linux-media-16.5-55964.el7.x86_64.rpm
SDK2017Production16.5/CentOS/kmod-ukmd-16.5-55964.el7.x86_64.rpm
SDK2017Production16.5/CentOS/intel-opencl-16.5-55964.x86_64.rpm
SDK2017Production16.5/CentOS/libva-devel-1.67.0.pre1-55964.el7.x86_64.rpm
SDK2017Production16.5/CentOS/drm-utils-2.4.66-55964.el7.x86_64.rpm
SDK2017Production16.5/CentOS/MediaSamples_Linux_bin-16.5-55964.tar.gz
SDK2017Production16.5/CentOS/vpg_ocl_linux_rpmdeb.public
SDK2017Production16.5/media_server_studio_sdk_release_notes.pdf
Libraries
The MediaSDK leverages libva to access the hardware together with an highly extended DRI kernel module.
They support CentOS with rpms and all the other distros with a tarball.

BEWARE: if you use the installer script the custom libva would override your system one, you might not want that.

I’m using Gentoo so it is intel-linux-media_generic_16.5-55964_64bit.tar.gz for me.

The bits of this tarball you really want to install in the system no matter what is the firmware:

./lib/firmware/i915/skl_dmc_ver1_26.bin
If you are afraid of adding custom stuff on your system I advise to offset the whole installation and then override the LD paths to use that only for Libav.

BEWARE: you must use the custom iHD libva driver with the custom i915 kernel module.

If you want to install using the provided script on Gentoo you should first emerge lsb-release.

emerge lsb-release
bash install_media.sh
source /etc/profile.d/*.sh
echo /opt/intel/mediasdk/lib64/ >> /etc/ld.so.conf.d/intel-msdk.conf
ldconfig
Kernel Modules
The patchset resides in:

opt/intel/mediasdk/opensource/patches/kmd/4.4/intel-kernel-patches.tar.bz2
The current set is 143 patches against linux 4.4, trying to apply on a more recent kernel requires patience and care.

The 4.4.27 works almost fine (even btrfs does not seem to have many horrible bugs).

Libav
In order to use the Media SDK with Libav you should use the mfx_dispatch from yours truly since it provides a default for Linux so it behaves in an uniform way compared to Windows.

Building the dispatcher
It is a standard autotools package.

git clone git://github.com/lu-zero/mfx_dispatch
cd mfx_dispatch
autoreconf -ifv
./configure --prefix=/some/where
make -j 8
make install
Building Libav
If you want to use the advanced hwcontext features on Linux you must enable both the vaapi and the mfx support.

git clone git://github.com/libav/libav
cd libav
export PKG_CONFIG_PATH=/some/where/lib/pkg-config
./configure --enable-libmfx --enable-vaapi --prefix=/that/you/like
make -j 8
make install

Troubleshooting

Media SDK is sort of temperamental and the setup process requires manual tweaking so the odds of having to do debug and investigate are high.

If something misbehave here is a checklist:
– Make sure you are using the right kernel and you are loading the module.

uname -a
lsmod
dmesg
  • Make sure libva is the correct one and it is loading the right thing.
vainfo
strace -e open ./avconv -c:v h264_qsv -i test.h264 -f null -
  • Make sure you aren’t using the wrong ratecontrol or not passing all the parameters required
./avconv -v verbose -filter_complex testsrc -c:v h264_qsv {ratecontrol params omitted} out.mkv
See below for some examples of working rate-control settings.
– Use the MediaSDK examples provided with the distribution to confirm that everything works in case the SDK is more recent than the updates.

Usage

The Media SDK support in Libav covers decoding, encoding, scaling and deinterlacing.

Decoding is straightforward, the rest has still quite a bit of rough edges and this blog post had been written mainly to explain them.

Currently the most interesting format supported are h264 and hevc, but even other formats such as vp8 and vc1 are supported.

./avconv -codecs | grep qsv
Decoding
The decoders can output directly to system memory and can be used as normal decoders and feed a software implementation just fine.

./avconv -c:v h264_qsv -i input.h264 -c:v av1 output.mkv
Or they can decode to opaque (gpu backed) buffers so further processing can happen

./avconv -hwaccel qsv -c:v h264_qsv -vf deinterlace_qsv,hwdownload,format=nv12 -c:v x265 output.mov
NOTICE: you have to explicitly pass the filterchain hwdownload,format=nv12 not have mysterious failures.

Encoding
The encoders are almost as straightforward beside the fact that the MediaSDK provides multiple rate-control systems and they do require explicit parameters to work.

./avconv -i input.mkv -c:v h264_qsv -q 20 output.mkv
Failing to set the nominal framerate or the bitrate would make the look-ahead rate control not happy at all.

Rate controls
The rate control is one of the most rough edges of the current MediaSDK support, most of them do require a nominal frame rate and that requires an explicit -r to be passed.

There isn’t a default bitrate so also -b:v should be passed if you want to use a rate-control that has a bitrate target.

Is it possible to use a look-ahead rate-control aiming to a quality metric passing -global_quality -la_depth.

Transcoding
It is possible to have a full hardware transcoding pipeline with Media SDK.

Deinterlacing

./avconv -hwaccel qsv -c:v h264_qsv -i input.mkv -vf deinterlace_qsv -c:v h264_qsv -r 25 -b:v 2M output.mov
Scaling

./avconv -hwaccel qsv -c:v h264_qsv -i input.mkv -vf scale_qsv=640:480 -c:v h264_qsv -r 25 -b:v 2M -la_depth 5 output.mov

Both at the same time

./avconv -hwaccel qsv -c:v h264_qsv -i input.mkv -vf deinterlace_qsv,scale_qsv=640:480 -c:v h264_qsv -r 25 -b:v 2M -la_depth 5 output.mov
Hardware filtering caveats
The hardware filtering system is quite new and introducing it shown a number of shortcomings in the Libavfilter architecture regarding format autonegotiation so for hybrid pipelines (those that do not keep using hardware frames all over) it is necessary to explicitly call for hwupload and hwdownload explictitly in such ways:

./avconv -hwaccel qsv -c:v h264_qsv -i in.mkv -vf deinterlace_qsv,hwdownload,format=nv12 -c:v vp9 out.mkv

Future for MediaSDK in Libav

The Media SDK supports already a good number of interesting codecs (h264, hevc, vp8/vp9) and Intel seems to be quite receptive regarding what codecs support.
The Libav support for it will improve over time as we improve the hardware acceleration support in the filtering layer and we make the libmfx interface richer.

We’d need more people testing and helping us to figure use-cases and corner-cases that hadn’t been thought of yet, your feedback is important!
Top

Happy 19th Birthday, Noah

Postby Zach via The Z-Issue »

Happy 19th Birthday, Noah! I hope that, this year, you are able to spend your special day with family, friends and loved ones. Be safe out there, and have a good time!

I also wanted to let you know how proud I am of all that you’ve accomplished, and I hope that you are too. Juggling undergraduate studies (with classes, lectures, homework, and the likes) along with a job that carries with it a lot of hours is no easy task, but you are managing to do it quite well! Keep it up, and I know that you will go far in this life.

Love you, buddy,
Zach
Top

Are the Days of “Booter” Services Numbered?

Postby BrianKrebs via Krebs on Security »

It may soon become easier for Internet service providers to anticipate and block certain types of online assaults launched by Web-based attack-for-hire services known as “booter” or “stresser” services, new research released today suggests.

The findings come from researchers in Germany who’ve been studying patterns that emerge when miscreants attempt to mass-scan the entire Internet looking for systems useful for launching these digital sieges — known as “distributed denial-of-service” or DDoS attacks.



To understand the significance of their research, it may help to briefly examine how DDoS attacks have evolved. Not long ago, if one wanted to take down large Web site, one had to build and maintain a large robot network, or “botnet,” of hacked computers — which is a fairly time intensive, risky and technical endeavor.

These days, however, even the least sophisticated Internet user can launch relatively large DDoS attacks just by paying a few bucks for a subscription to one of dozens of booter or stresser services, some of which even accept credit cards and PayPal payments.

These Web-based DDoS-for-hire services don’t run on botnets: They generally employ a handful of powerful servers that are rented from some dodgy “bulletproof” hosting provider. The booter service accepts payment and attack instructions via a front end Web site that is hidden behind Cloudflare (a free DDoS protection service).

But the back end of the booter service is where the really interesting stuff happens. Virtually all of the most powerful and effective attack types used by booter services rely on a technique called traffic amplification and reflection, in which the attacker can reflect or “spoof” 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.

To find vulnerable systems that can be leveraged this way, booters employ large-scale Internet scanning services that constantly seek to refresh the list of systems that can be used for amplification and reflection attacks. They do this because, as research has shown (PDF), anywhere from 40-50 percent of the amplifiers vanish or are reassigned new Internet addresses after one week.

Enter researchers from Saarland University in Germany, as well as the Yokohama National University and National Institute of Information and Communications Technology — both in Japan. In a years-long project first detailed in 2015, the researchers looked for scanning that appeared to be kicked off by ne’er-do-wells running booter services.

To accomplish this, the research team built a kind of distributed “honeypot” system — which they dubbed “AmpPot” — designed to mimic services known to be vulnerable to amplification attacks, such as DNS and NTP floods.

“To make them attractive to attackers, our honeypots send back legitimate responses,” the researchers wrote in a 2015 paper (PDF). “Attackers, in turn, will abuse these honeypots as amplifiers, which allows us to observe ongoing attacks, their victims, and the DDoS techniques. To prevent damage caused by our honeypots, we limit the response rate. This way, while attackers can still find these ratelimited honeypots, the honeypots stop replying in the face of attacks.”

In that 2015 paper, the researchers said they deployed 21 globally-distributed AmpPot instances, which observed more than 1.5 million attacks between February and May 2015. Analyzing the attacks more closely, they found that more than 96% of the attacks stem from single sources, such as booter services.

“When focusing on amplification DDoS attacks, we find that almost all of them (>96%) are caused by single sources (e.g. booters), and not botnets,” the team concluded. “However, we sadly do not have the numbers to compare this [to] DoS attacks in general.”

Many large-scale Internet scans like the ones the researchers sought to measure are launched by security firms and other researchers, so the team needed a way to differentiate between scans launched by booter services and those conducted for research or other benign purposes.

“To distinguish between scans performed by researchers and scans performed with malicious intent we relied on a simple assumption: That no attack would be based on the results of a scan performed by (ethical) researchers,” said Johannes Krupp, one of the main authors of the report. “In fact, thanks to our methodology, we do not have to make this distinction upfront, but we can rather look at the results and say: ‘We found attacks linked to this scanner, therefore this scanner must have been malicious.’ If a scan was truly performed by benign parties, we will not find attacks linked to it.”

SECRET IDENTIFIERS

What’s new in the paper being released today by students at Saarland University’s Center for IT-Security, Privacy and Accountability (CISPA) is the method by which the researchers were able to link these mass-scans to the very amplification attacks that follow soon after.

The researchers worked out a way to encode a secret identifier into the set of AmpPot honeypots that any subsequent attack will use, which varies per scan source. They then tested to see if the scan infrastructure was also used to actually launch (and not just to prepare) the attacks.

Their scheme was based in part on the idea that similar traffic sources should have to travel similar Internet distances to reach the globally-distributed AmpPot sensors. To do this, they looked at the number of “hops” or Internet network segments that each scan and attack had to traverse.

Using trilateration –the process of determining absolute or relative locations of points by measurement of distances — the research team was able to link scanners to attack origins based on hop counts.

These methods revealed some 286 scanners that are used by booter services in preparation for launching amplification attacks. Further, they discovered that roughly 75 percent of those scanners are located in the United States.

The researchers say they were able to confirm that many of the same networks that host scanners are also being used to launch the attacks. More significantly, they were able to attribute approximately one-third of the attacks back to their origin.

“This is an impressive result, given that the spoofed source of amplification attacks usually remains hidden,” said Christian Rossow of Saarland University.

Rosso said the team hopes to conduct further research on their methods to more definitively tie scanning and attack activity to specific booter services by name. The group is already offering a service to hosting providers and ISPs to share information about incidents (such as attack start and end times). Providers can then use the attack information to inform their customers or to filter attack traffic.

“We have shared our findings with law enforcement agencies — in particular, Europol and the FBI — and a closed circle of tier-1 network providers that use our insights on an operational basis,” the researchers wrote. “Our output can be used as forensic evidence both in legal complaints and in ways to add social pressure against spoofing sources.”

ANALYSIS

Even if these newly-described discovery methods were broadly deployed today, it’s unlikely that booter services would be going away anytime soon. But this research certainly holds the promise that booter service owners will be able to hide the true location of their operations less successfully going forward. and that perhaps more of them will be held accountable for their crimes.

Efforts by other researchers have made it more difficult for booter and stresser services to accept PayPal payments, forcing more booters to rely more on Bitcoin.

Also, there are a number of initiatives that seek to identify a handful of booter services which resell their infrastructure to other services who brand and market them as their own. Case in point, in September 2016 I published an expose on vDOS, a booter service that earned (conservatively) $600,000 over two years helping to launch more than 150,000 DDoS attacks.

Turns out, vDOS’s infrastructure was used by more than a half-dozen other booter services, and shortly after vDOS was taken offline most of those services went dark or were dismantled as well.

One major shift that could help to lessen the appeal of booter services — both for the profit-seeking booter proprietors and their customers — is a clear sign from law enforcement officials that this activity is in fact illegal and punishable by real jail time. So far, many booter service owners have been operating under the delusion or rationalization that their services are intended solely for Web site owners to test the ability of their sites to withstand data deluges. The recent arrest of two alleged Lizard Squad members who resold vDOS services through their own “PoodleStresser” service is a good start.

Many booter operators apparently believe (or at least hide behind) a wordy “terms of service” agreement that all customers must acknowledge somehow absolves them of any sort of liability for how their customers use the service — regardless of how much hand-holding and technical support they offer those customers.

Indeed, the proprietors of vDOS — who were arrested shortly after my story about them — told the Wall Street Journal through their attorneys that, “If I was to buy a gun and shoot something, is the person that invents the gun guilty?”

The alleged proprietors of vDOS — 18-year-old Israelis Yarden Bidani and Itay Huri — were released from house arrest roughly ten days after their initial arrest. To date, no charges have been filed against either men, but I have reason to believe that may not be the case for long.

Meanwhile, changes may be afoot for booter services advertised at Hackforums[dot]net, probably the biggest open-air online marketplace where booter services are advertised, compared and rated (hat tip to @MalwareTechblog). Earlier this week, Hackforums administrator Jesse “Omniscient” LaBrocca began restricting access to its “stressers” subsection of the sprawling forum, and barring forum members from advertising booter services in their user profiles.

“I can absolutely see a day when it’s removed entirely,” LaBrocca said in a post explaining his actions. “Could be very soon too.”

Hackforums administrator Jesse “Omniscient” LaBrocca explaining a decision to restrict access to the “stressers” portion of the Hackforums marketplace.
My worry is that we may soon see a pendulum shift in the way that many booter services operate. For now, the size of attacks launched by booter services is somewhat dependent on the number and power of the back-end servers used to initiate amplification and reflection attacks.

However, I could see a day in the not-too-distant future in which booter service operators start earning most of their money by reselling far more powerful attacks launched by actual botnets made from large networks of hacked Internet of Things (IoT) devices — such as poorly-secured CCTV cameras and digital video recorders (DVRs).

In some ways this has already happened, as I detailed in my January 2015 story, Lizard Stresser Runs on Hacked Home Routers. But with the now public release of the source code for the Mirai botnet — the same malware strain that was used in the record 620 Gbps DDoS on my site last month and in the widespread Internet outage last week caused by an attack against infrastructure provider Dyn — far more powerful and scalable attacks are now available for resale.

A copy of the paper released today at the ACM CSS conference in Vienna is available here (PDF).
Top

Cross-posts from GitHub Gists: Ceph RGW StaticSites documentation, and S3 Boto magic

Postby Robbat2 via Move along, nothing to read »

Cross-posting from where I've written up some other pieces:
-
Top

Senator Prods Federal Agencies on IoT Mess

Postby BrianKrebs via Krebs on Security »

The co-founder of the newly launched Senate Cybersecurity Caucus is pushing federal agencies for possible solutions and responses to the security threat from insecure “Internet of Things” (IoT) devices, such as the network of hacked security cameras and digital video recorders that were reportedly used to help bring about last Friday’s major Internet outages.

In letters to the Federal Communications Commission (FCC), the Federal Trade Commission (FTC) and the Department of Homeland Security (DHS), Virginia Senator Mark Warner (D) called the proliferation of insecure IoT devices a threat to resiliency of the Internet.

“Manufacturers today are flooding the market with cheap, insecure devices, with few market incentives to design the products with security in mind, or to provide ongoing support,” Warner wrote to the agencies. “And buyers seem unable to make informed decisions between products based on their competing security features, in part because there are no clear metrics.”

The letter continues:

“Because the producers of these insecure IoT devices currently are insulated from any standards requirements, market feedback, or liability concerns, I am deeply concerned that we are witnessing a ‘tragedy of the commons’ threat to the continued functioning of the internet, as the security so vital to all internet users remains the responsibility of none. Further, buyers have little recourse when, despite their best efforts, security failures occur” [link added].

As Warner’s letter notes, last week’s attack on online infrastructure provider Dyn was launched at least in part by Mirai, a now open-source malware strain that scans the Internet for routers, cameras, digital video recorders and other Internet of Things “IoT” devices protected only by the factory-default passwords.

Once infected with Mirai, the IoT systems can be used to flood a target with so much junk Web traffic that the target site can no longer accommodate legitimate users or visitors. The attack on Dyn was slightly different because it resulted in prolonged outages for many other networks and Web sites, including Netflix, PayPal, Reddit and Twitter.

As a result of that attack, one of the most-read stories on KrebsOnSecurity so far this year is “Who Makes the IoT Things Under Attack?“, in which I tried to match default passwords sought out by the Mirai malware with IoT hardware devices for sale on the commercial market today.

In a follow-up to that story, I interviewed researchers at Flashpoint who discovered that one of the default passwords sought by machines infected with Mirai — username: root and password: xc3511 — is embedded in a broad array of white-labeled DVR and IP camera electronics boards made by a Chinese company called XiongMai Technologies. These components are sold downstream to vendors who then use them in their own products (for a look at XionMai’s response to all this, see Monday’s story, IoT Device Maker Vows Product Recall, Legal Action Against Western Accusers).

In his inquiry to the federal agencies, Warner asked whether there was more the government could be doing to vet the security of IoT devices before or after they are plugged into networks.

“In the FCC’s Open Internet Order, the Commission suggested that ISPs could take such steps only when addressing ‘traffic that constitutes a denial-of-service attack on specific network infrastructure elements,'” Warner wrote in his missive to the FCC.  “Is it your agency’s opinion that the Mirai attack has targeted ‘specific network infrastructure elements’ to warrant a response from ISPs?”

In another line of questioning, Warner also asked whether it would it be a reasonable network management practice for ISPs to designate insecure network devices as “insecure” and thereby deny them connections to their networks, including by refraining from assigning devices IP addresses.

It’s good to see lawmakers asking questions about whether there is a market failure here that requires government intervention or regulation. Judging from the comments on my story earlier this month — Europe to Push New Security Rules Amid IoT Mess — KrebsOnSecurity readers remain fairly divided on the role of government in addressing the IoT problem.

I have been asked by several reporters over the past few days whether I think government has a role to play in fixing the IoT mess. Personally, I do not believe there has ever been a technology challenge that was best served by additional government regulation.

However, I do believe that the credible threat of government regulation is very often what’s needed to spur the hi-tech industry into meaningful action and self-regulation. And that process usually starts with inquiries like these. So, here’s hoping more lawmakers in Congress can get up to speed quickly on this vitally important issue.

Sen. Warner’s letter to the FCC looks very similar to those sent to the other two agencies. A copy of it is available here.
Top

FreeBSD on Intel NUCs

Postby Murray Stokely via Murray's FreeBSD Notes »

I've been away from FreeBSD for a few years but I wanted some more functionality on my home network that I was able to configure with my Synology NAS and router. Specifically, I wanted:

  • a configurable caching name server that would serve up authoritative private names on my LAN and also validates responses with DNSSEC.
  • a more configurable DHCP server so I could make the server assign specific IPs to specific MAC addresses.
  • more compute power for transcoding videos for Plex.
Running FreeBSD 11 on an Intel NUC seemed like an ideal solution to keep my closet tidy. As of this week, $406.63 on Amazon buys a last generation i3 Intel NUC mini PC (NUC5I3RYH), with 8GB of RAM and 128GB of SSD storage. This was the first model I tried since I found reports of others using this with FreeBSD online, but I was also able to get it working on the newer generation i5 based NUC6i5SYK with 16GB of RAM and 256GB of SSD. The major issue with these NUCs is that the Intel wireless driver is not supported in FreeBSD. I am not doing anything graphical with these boxes so I don't know how well the graphics work, but they are great little network compute nodes.

Installation

I downloaded the FreeBSD 11 memory stick images, and was pleased to see that the device booted fine off the memory stick without any BIOS configuration required. However, my installation failed trying to mount root ("Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19."). Installation from an external USB DVD drive and over the network with PXE both proved more successful at getting me into bsdinstaller to complete the installation.

I partitioned the 128GB SSD device with 8GB of swap and the rest for the root partition (UFS, Journaled and Soft Updates). After installation I edited /etc/fstab to add a tmpfs(5) mount for /tmp. The dmesg output for this host is available in a Gist on Github.

Warren Block's article on SSD on FreeBSD and the various chapters of the FreeBSD Handbook were helpful. There were a couple of tools that were also useful in probing the performance of the SSD with my FreeBSD workload:

  • The smartctl tool in the sysutils/smartmontools package allows one to read detailed diagnostic information from the SSD, including wear patterns.
  • The basic benchmark built into diskinfo -t reports that the SSD is transferring 503-510MB/second.
But how well does it perform in practice?

Rough Benchmarks

This post isn't meant to report a comprehensive suite of FreeBSD benchmarks, but I did run some basic tests to understand how suitable these low power NUCs perform in practice. To start with, I downloaded the 11-stable source from Subversion and measured the build times to understand performance of the new system. All builds were done with a minimal 2 line make.conf:

MALLOC_PRODUCTION=yes
CPUTYPE?=core2

Build Speed

Build CommandEnvironmentReal Times
make -j4 buildkernel/usr/src and /usr/obj on SSD10.06 minutes
make -j4 buildkernel/usr/src on SSD, /usr/obj on tmpfs9.65 minutes
make -j4 buildworld/usr/src and /usr/obj on SSD1.27 hours
make buildworld/usr/src and /urs/obj on SSD3.76 hours

Bonnie

In addition to the build times, I also wanted to look more directly at the performance reading from flash and reading from the NFS mounted home directories on my 4-drive NAS. I first tried Bonnie++, but then ran into a 13-year old bug in the NFS client of FreeBSD. After switching to Bonnie, I was able to gather some reasonable numbers. I had to use really large file sizes for the random write test to eliminate most of the caching that was artificially inflating the results. For those that haven't seen it, Brendan Gregg's excellent blog post highlights some of the issues of file system benchmarks like Bonnie.
Average of 3 bonnie runs with 40GB block size
ConfigurationRandom I/OBlock InputBlock Output
Seeks/SecCPU UtilizationReads/secCPU UtilizationWrites/secCPU Utilization
NFS99.20.91065054.8899667.5
SSD880913.553867125.3316091711.3

The block input rates from my bonnie benchmarks on the SSD were within 5% of the value provided by the much quick and dirtier diskinfo -t test.

Running Bonnie with less than 40GB file size yielded unreliable benchmarks due to caching at the VM layer. The following boxplot shows the random seek performance during 3 runs each at 24, 32, and 40GB file sizes. Performance starts to even off at this level but with smaller file sizes the reported random seek performance is much higher.

Open Issues

As mentioned earlier, I liked the performance I got with running FreeBSD on a 2015-era i3 NUC5I3RYH so much that I bought a newer, more powerful second device for my network. The 2016-era i5 NUC 6i5SYK is also running great. There are just a few minor issues I've encountered so far:

  • There is no FreeBSD driver for the Intel Wireless chip included with this NUC. Code for other platforms exists but has not been ported to FreeBSD.
  • The memory stick booting issue described in the installation section. It is not clear if it didn't like my USB stick for some reason, or the port I was plugging into, or if additional boot parameters would have solved the issue. Documentation and/or code needs to be updated to make this clearer.
  • Similarly, the PXE Install instructions were a bit scattered. The PXE section of the Handbook isn't specifically targetting new manual installations into bsdinstall. There are a few extra things you can run into that aren't documented well or could be streamlined.
  • Graphics / X11 are outside of the scope of my needs. The NUCs have VESA mounts so you can easily tuck them behind an LCD monitor, but it is not clear to me how well they perform in that role.
Top

This week in vc4 (2016-10-24): HDMI audio, DSI, simulator, linux-next

Postby Eric Anholt via anholt's lj »

The most interesting work I did last week was starting to look into HDMI audio.  I've been putting this off because really I'm a 3D developer, not modesetting, and I'm certainly not an audio developer.  But the work needs to get done, so here I am.

HDMI audio on SOCs looks like it's not terribly hard.  VC4's HDMI driver needs to instantiate a platform device for audio when it gets loaded, and attach a function table to it for calls to be made when starting/stopping audio.  Then I write a sound driver that will bind to the node that VC4 created, accepting a parameter of which register to DMA into.  That sound driver will tell ALSA about what formats it can acccept and actually drive the DMA engine to write audio frames into HDMI.  On the VC4 HDMI side, we do a bit of register setup (clocks, channel mappings, and the HDMI audio infoframe) when the sound driver tells us it wants to start.

It all sounds pretty straightforward so far.  I'm currently at the "lots of typing" stage of development of this.

Second, I did a little poking at the DSI branch again.  I've rebased onto 4.9 and tested an idea I had for how DSI might be failing.  Still no luck.  There's code on drm-vc4-dsi-panel-restart-cleanup-4.9, and the length of that name suggests how long I've been bashing my head against DSI.  I would love for anyone out there with the inclination to do display debug to spend some time looking into it.  I know the history there is terrible, but I haven't prioritized cleanup while trying to get the driver working in the first place.

I also finished the simulator cleanup from last week, found a regression in the major functional improvement in the cleanup, and landed what worked.  Dave Airlie pointed out that he took a different approach for testing with virgl called vtest, and I took a long look at that.  Now that I've got my partial cleanup in place, the vtest-style simulator wrapper looks a lot more doable, and if it doesn't have the major failing that swrast did with visuals then it should actually make vc4 simulation more correct.

I landed a very tiny optimization to Mesa that I wrote while debugging DEQP failures.

Finally, I put together the -next branches for upstream bcm2835 now that 4.9-rc1 is out.  So far I've landed a major cleanup of pinctrl setup in the DT (started by me and finished by Gerd Hoffmann from Red Hat, to whom I'm very grateful) and a little USB setup fix.  I did a lot of review of VCHIQ patches for staging, and sort of rewrote Linus Walleij's RFC patch for getting descriptive names for the GPIOs in lsgpio.
Top

IoT Device Maker Vows Product Recall, Legal Action Against Western Accusers

Postby BrianKrebs via Krebs on Security »

A Chinese electronics firm pegged by experts as responsible for making many of the components leveraged in last week’s massive attack that disrupted Twitter and dozens of popular Web sites has vowed to recall some of its vulnerable products, even as it threatened legal action against this publication and others for allegedly tarnishing the company’s brand.



Last week’s attack on online infrastructure provider Dyn was launched at least in part by Mirai, a now open-source malware strain that scans the Internet for routers, cameras, digital video recorders and other Internet of Things “IoT” devices protected only by the factory-default passwords. Once infected with Mirai, the IoT systems can be used to flood a target with so much junk Web traffic that the target site can no longer accommodate legitimate users or visitors.

In an interim report on the attack, Dyn said: “We can confirm, with the help of analysis from Flashpoint and Akamai, that one source of the traffic for the attacks were devices infected by the Mirai botnet. We observed 10s of millions of discrete IP addresses associated with the Mirai botnet that were part of the attack.”

As a result of that attack, one of the most-read stories on KrebsOnSecurity so far this year is “Who Makes the IoT Things Under Attack?“, in which I tried to match default passwords sought out by the Mirai malware with IoT hardware devices for sale on the commercial market today.

In a follow-up to that story, I interviewed researchers at Flashpoint who discovered that one of the default passwords sought by machines infected with Mirai — username: root and password: xc3511 — is embedded in a broad array of white-labeled DVR and IP camera electronics boards made by a Chinese company called XiongMai Technologies. These components are sold downstream to vendors who then use them in their own products.

The scary part about IoT products that include XiongMai’s various electronics components, Flashpoint found, was that while users could change the default credentials in the devices’ Web-based administration panel, the password is hardcoded into the device firmware and the tools needed to disable it aren’t present.

In a statement issued on social media Monday, XiongMai (referring to itself as “XM”) said it would be issuing a recall on millions of devices — mainly network cameras.

“Mirai is a huge disaster for the Internet of Things,” the company said in a separate statement emailed to journalists. “XM have to admit that our products also suffered from hacker’s break-in and illegal use.”

At the same time, the Chinese electronics firm said that in September 2015 it issued a firmware fix for vulnerable devices, and that XiongMai hardware shipped after that date should not by default be vulnerable.

“Since then, XM has set the device default Telnet off to avoid the hackers to connect,” the company said. “In other words, this problem is absent at the moment for our devices after Sep 2015, as Hacker cannot use the Telnet to access our devices.”

Regarding the default user name/password that ships with XM, “our devices are asking customers to change the default password when they first time to login,” the electronics maker wrote. “When customer power on the devices, the first step, is change the default password.”

I’m working with some researchers who are testing XM’s claims, and will post an update here if and when that research is available. In the meantime, XM is threatening legal action against media outlets that it says are issuing “false statements” against the company.

Google’s translation of their statement reads, in part: “Organizations or individuals false statements, defame our goodwill behavior … through legal channels to pursue full legal responsibility for all violations of people, to pursue our legal rights are reserved.”

Xiongmail’s electrical components that are white-labeled and embedded in countless IoT products sold under different brand names.
The statement by XM’s lawyers doesn’t name KrebsOnSecurity per se, but instead links to a Chinese media story referencing this site under the heading, “untrue reports link.”

Brian Karas, a business analyst with IPVM — a subscription-based news, testing and training site for the video surveillance industry which first reported the news of potential litigation by XM — said that over the past five years China’s market share in the video surveillance industry has surged, due to the efforts of companies like XiongMai and Dahua to expand globally, and from the growth of government-controlled security company Hikvision.

Karas said the recent Mirai botnet attacks have created “extreme concerns about the impact of Chinese video surveillance products.” Nevertheless,  he said, the threats against those the company accuses of issuing false statements are more about saving face.

“We believe Xiongmai has issued this announcement as a PR effort within China, to help counter criticisms they are facing,” Karas wrote. “We do not believe that Xiongmai or the Ministry of Justice is seriously going to sue any Western companies as this is a typical tactic to save face.”

Update,Oct. 25, 8:47 a.m.: Updated the story to reflect an oddity of Google Translate, which translated the statement from XM’s legal department as Justice Ministry. The threats of litigation come from XM, not the Chinese government. Also made clear that the threat was first written about by IPVM.
Top

jasper: NULL pointer dereference in jp2_colr_destroy (jp2_cod.c) (incomplete fix for CVE-2016-8887)

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 on an updated version (1.900.10) revealed that the NULL pointer access identified as CVE-2016-8887 which upstream declared to be fixed in the version 1.900.10 is still here.

The complete ASan output:

# imginfo -f $FILE
ASAN:DEADLYSIGNAL
=================================================================
==20885==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000041defd bp 0xbebebebebebebebe sp 0x7ffc4e4a4550 T0)
    #0 0x41defc in atomic_compare_exchange_strong /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang.h:81
    #1 0x41defc in __asan::Allocator::AtomicallySetQuarantineFlag(__asan::AsanChunk*, void*, __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:465
    #2 0x41defc in __asan::Allocator::Deallocate(void*, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:525
    #3 0x41defc in __asan::asan_free(void*, __sanitizer::BufferedStackTrace*, __asan::AllocType) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:709
    #4 0x4c008c 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:41
    #5 0x7faeeeb2d430 in jp2_colr_destroy /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jp2/jp2_cod.c:450:3
    #6 0x7faeeeb32b0e in jp2_box_destroy /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jp2/jp2_cod.c:211:3
    #7 0x7faeeeb32b0e in jp2_box_get /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jp2/jp2_cod.c:314
    #8 0x7faeeeb369a0 in jp2_decode /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jp2/jp2_dec.c:156:16
    #9 0x7faeeeac6a29 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/base/jas_image.c:392:16
    #10 0x4f1686 in main /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/appl/imginfo.c:188:16
    #11 0x7faeedbd361f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #12 0x418e68 in _init (/usr/bin/imginfo+0x418e68)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang.h:81 in atomic_compare_exchange_strong
==20885==ABORTING
Affected version:
1.900.10

Fixed version:
1.900.13

Commit fix:
https://github.com/mdadams/jasper/commit/bdfe95a6e81ffb4b2fad31a76b57943695beed20

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

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00002-jasper-NULLptr-jp2_colr_destroy

Timeline:
2016-10-22: bug re-discovered
2016-10-22: bug re-reported to upstream
2016-10-23: blog post about the issue
2016-10-23: upstream released a patch and 1.900.13

Note:
This bug was found with American Fuzzy Lop.

Permalink:

jasper: NULL pointer dereference in jp2_colr_destroy (jp2_cod.c) (incomplete fix for CVE-2016-8887)

Top

jasper: heap-based buffer overflow in jpc_dec_tiledecode (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 on an updated version (1.900.10) a buffer over read because of an integer overflow.

The complete ASan output:

# imginfo -f $FILE
warning: not enough tile data (9 bytes)                                                                                                                                                        
=================================================================                                                                                                                              
==15870==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f0c6a964770 at pc 0x7f0c729e93a4 bp 0x7ffd08758cf0 sp 0x7ffd08758ce8                                                      
READ of size 8 at 0x7f0c6a964770 thread T0                                                                                                                                                     
    #0 0x7f0c729e93a3 in jpc_dec_tiledecode /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jpc/jpc_dec.c:1126:43                                                   
    #1 0x7f0c729d9567 in jpc_dec_process_eoc /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jpc/jpc_dec.c:1170:8                                                   
    #2 0x7f0c729e20c4 in jpc_dec_decode /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jpc/jpc_dec.c:390:10                                                        
    #3 0x7f0c729e20c4 in jpc_decode /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jpc/jpc_dec.c:254                                                               
    #4 0x7f0c729afc41 in jp2_decode /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jp2/jp2_dec.c:215:21                                                            
    #5 0x7f0c7293fa29 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/base/jas_image.c:392:16                                                   
    #6 0x4f1686 in main /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/appl/imginfo.c:188:16                                                                                 
    #7 0x7f0c71a4c61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                        
    #8 0x418e68 in _init (/usr/bin/imginfo+0x418e68)                                                                                                                                           

0x7f0c6a964770 is located 0 bytes to the right of 64749424-byte region [0x7f0c66ba4800,0x7f0c6a964770)                                                                                         
allocated by thread T0 here:                                                                                                                                                                   
    #0 0x4c03b8 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 0x7f0c7297efbe in jas_malloc /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/base/jas_malloc.c:105:11                                                        
    #2 0x7f0c7297efbe in jas_alloc2 /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/base/jas_malloc.c:136                                                           
    #3 0x7f0c7297fb44 in jas_matrix_create /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/base/jas_seq.c:129:25                                                    
    #4 0x7f0c7297f71b in jas_seq2d_create /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/base/jas_seq.c:90:17                                                      
    #5 0x7f0c729d4280 in jpc_dec_tileinit /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jpc/jpc_dec.c:702:23                                                      
    #6 0x7f0c729d4280 in jpc_dec_process_sod /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jpc/jpc_dec.c:559                                                      
    #7 0x7f0c729e20c4 in jpc_dec_decode /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jpc/jpc_dec.c:390:10                                                        
    #8 0x7f0c729e20c4 in jpc_decode /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jpc/jpc_dec.c:254                                                               
    #9 0x7f0c729afc41 in jp2_decode /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jp2/jp2_dec.c:215:21                                                            
    #10 0x7f0c7293fa29 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/base/jas_image.c:392:16                                                  
    #11 0x4f1686 in main /tmp/portage/media-libs/jasper-1.900.10/work/jasper-1.900.10/src/appl/imginfo.c:188:16
    #12 0x7f0c71a4c61f 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/jasper-1.900.10/work/jasper-1.900.10/src/libjasper/jpc/jpc_dec.c:1126:43 in jpc_dec_tiledecode
Shadow bytes around the buggy address:
  0x0fe20d524890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe20d5248a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe20d5248b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe20d5248c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe20d5248d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fe20d5248e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa
  0x0fe20d5248f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe20d524900: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe20d524910: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe20d524920: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe20d524930: 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
==15870==ABORTING
Affected version:
1.900.10

Fixed version:
1.900.12

Commit fix:
https://github.com/mdadams/jasper/commit/988f8365f7d8ad8073b6786e433d34c553ecf568

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

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00001-jasper-heapoverflow-jpc_dec_tiledecode

Timeline:
2016-10-22: bug discovered
2016-10-22: bug reported to upstream
2016-10-22: upstream released the patch
2016-10-23: upstream released 1.900.12
2016-10-23: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

jasper: heap-based buffer overflow in jpc_dec_tiledecode (jpc_dec.c)

Top

Hacked Cameras, DVRs Powered Today’s Massive Internet Outage

Postby BrianKrebs via Krebs on Security »

A massive and sustained Internet attack that has caused outages and network congestion today for a large number of Web sites was launched with the help of hacked “Internet of Things” (IoT) devices, such as CCTV video cameras and digital video recorders, new data suggests.

Earlier today cyber criminals began training their attack cannons on Dyn, an Internet infrastructure company that provides critical technology services to some of the Internet’s top destinations. The attack began creating problems for Internet users reaching an array of sites, including Twitter, Amazon, Tumblr, Reddit, Spotify and Netflix.

A depiction of the outages caused by today’s attacks on Dyn, an Internet infrastructure company. Source: Downdetector.com.
At first, it was unclear who or what was behind the attack on Dyn. But over the past few hours, at least one computer security firm has come out saying the attack involved Mirai, the same malware strain that was used in the record 620 Gpbs attack on my site last month. At the end September 2016, the hacker responsible for creating the Mirai malware released the source code for it, effectively letting anyone build their own attack army using Mirai.

Mirai scours the Web for IoT devices protected by little more than factory-default usernames and passwords, and then enlists the devices in attacks that hurl junk traffic at an online target until it can no longer accommodate legitimate visitors or users.

According to researchers at security firm Flashpoint, today’s attack was launched at least in part by a Mirai-based botnet. Allison Nixon, director of research at Flashpoint, said the botnet used in today’s ongoing attack is built on the backs of hacked IoT devices — mainly compromised digital video recorders (DVRs) and IP cameras made by a Chinese hi-tech company called XiongMai Technologies. The components that XiongMai makes are sold downstream to vendors who then use it in their own products.

“It’s remarkable that virtually an entire company’s product line has just been turned into a botnet that is now attacking the United States,” Nixon said, noting that Flashpoint hasn’t ruled out the possibility of multiple botnets being involved in the attack on Dyn.

“At least one Mirai [control server] issued an attack command to hit Dyn,” Nixon said. “Some people are theorizing that there were multiple botnets involved here. What we can say is that we’ve seen a Mirai botnet participating in the attack.”

As I noted earlier this month in Europe to Push New Security Rules Amid IoT Mess, many of these products from XiongMai and other makers of inexpensive, mass-produced IoT devices are essentially unfixable, and will remain a danger to others unless and until they are completely unplugged from the Internet.

That’s because while many of these devices allow users to change the default usernames and passwords on a Web-based administration panel that ships with the products, those machines can still be reached via more obscure, less user-friendly communications services called “Telnet” and “SSH.”

Telnet and SSH are command-line, text-based interfaces that are typically accessed via a command prompt (e.g., in Microsoft Windows, a user could click Start, and in the search box type “cmd.exe” to launch a command prompt, and then type “telnet” to reach a username and password prompt at the target host).

“The issue with these particular devices is that a user cannot feasibly change this password,” Flashpoint’s Zach Wikholm told KrebsOnSecurity. “The password is hardcoded into the firmware, and the tools necessary to disable it are not present. Even worse, the web interface is not aware that these credentials even exist.”

Flashpoint’s researchers said they scanned the Internet on Oct. 6 for systems that showed signs of running the vulnerable hardware, and found more than 515,000 of them were vulnerable to the flaws they discovered.

“I truly think this IoT infrastructure is very dangerous on the whole and does deserve attention from anyone who can take action,” Flashpoint’s Nixon said.

It’s unclear what it will take to get a handle on the security problems introduced by millions of insecure IoT devices that are ripe for being abused in these sorts of assaults.

As I noted in The Democratization of Censorship, to address the threat from the mass-proliferation of hardware devices such as Internet routers, DVRs and IP cameras that ship with default-insecure settings, we probably need an industry security association, with published standards that all members adhere to and are audited against periodically.

The wholesalers and retailers of these devices might then be encouraged to shift their focus toward buying and promoting connected devices which have this industry security association seal of approval. Consumers also would need to be educated to look for that seal of approval. Something like Underwriters Laboratories (UL), but for the Internet, perhaps.

Until then, these insecure IoT devices are going to stick around like a bad rash — unless and until there is a major, global effort to recall and remove vulnerable systems from the Internet. In my humble opinion, this global cleanup effort should be funded mainly by the companies that are dumping these cheap, poorly-secured hardware devices onto the market in an apparent bid to own the market. Well, they should be made to own the cleanup efforts as well.

Devices infected with Mirai are instructed to scour the Internet for IoT devices protected by more than 60 default usernames and passwords. The entire list of those passwords — and my best approximation of which firms are responsible for producing those hardware devices — can be found at my story, Who Makes the IoT Things Under Attack.

Update 10:30 a.m., Oct. 22: Corrected attribution on outage graphic.
Top

DDoS on Dyn Impacts Twitter, Spotify, Reddit

Postby BrianKrebs via Krebs on Security »

Criminals this morning massively attacked Dyn, a company that provides core Internet services for Twitter, SoundCloud, Spotify, Reddit and a host of other sites, causing outages and slowness for many of Dyn’s customers.

Twitter is experiencing problems, as seen through the social media platform Hootsuite.
In a statement, Dyn said that this morning, October 21, Dyn received a global distributed denial of service (DDoS) attack on its DNS infrastructure on the east coast starting at around 7:10 a.m. ET (11:10 UTC).

“DNS traffic resolved from east coast name server locations are experiencing a service interruption during this time. Updates will be posted as information becomes available,” the company wrote.

DYN encouraged customers with concerns to check the company’s status page for updates and to reach out to its technical support team.

A DDoS is when crooks use a large number of hacked or ill-configured systems to flood a target site with so much junk traffic that it can no longer serve legitimate visitors.

DNS refers to Domain Name System services. DNS is an essential component of all Web sites, responsible for translating human-friendly Web site names like “example.com” into numeric, machine-readable Internet addresses. Anytime you send an e-mail or browse a Web site, your machine is sending a DNS look-up request to your Internet service provider to help route the traffic.

ANALYSIS

The attack on DYN comes just hours after DYN researcher Doug Madory presented a talk on DDoS attacks in Dallas, Texas at a meeting of the North American Network Operators Group (NANOG). Madory’s talk — available here on Youtube.com — delved deeper into research that he and I teamed up on to produce the data behind the story DDoS Mitigation Firm Has History of Hijacks.

That story (as well as one published earlier this week, Spreading the DDoS Disease and Selling the Cure) examined the sometimes blurry lines between certain DDoS mitigation firms and the cybercriminals apparently involved in launching some of the largest DDoS attacks the Internet has ever seen. Indeed, the record 620 Gbps DDoS against KrebsOnSecurity.com came just hours after I published the story on which Madory and I collaborated.

The record-sized attack that hit my site last month was quickly superseded by a DDoS against OVH, a French hosting firm that reported being targeted by a DDoS that was roughly twice the size of the assault on KrebsOnSecurity. As I noted in The Democratization of Censorship — the first story published after bringing my site back up under the protection of Google’s Project Shield — DDoS mitigation firms simply did not count on the size of these attacks increasing so quickly overnight, and are now scrambling to secure far greater capacity to handle much larger attacks concurrently.

The size of these DDoS attacks has increased so much lately thanks largely to the broad availability of tools for compromising and leveraging the collective firepower of so-called Internet of Things devices — poorly secured Internet-based security cameras, digital video recorders (DVRs) and Internet routers. Last month, a hacker by the name of Anna_Senpai released the source code for Mirai, a crime machine that enslaves IoT devices for use in large DDoS attacks. The 620 Gbps attack that hit my site last month was launched by a botnet built on Mirai, for example.

Interestingly, someone is now targeting infrastructure providers with extortion attacks and invoking the name Anna_senpai. According to a discussion thread started Wednesday on Web Hosting Talk, criminals are now invoking the Mirai author’s nickname in a bid to extort Bitcoins from targeted hosting providers.

“If you will not pay in time, DDoS attack will start, your web-services will
go down permanently. After that, price to stop will be increased to 5 BTC
with further increment of 5 BTC for every day of attack.

NOTE, i?m not joking.

My attack are extremely powerful now – now average 700-800Gbps, sometimes over 1 Tbps per second. It will pass any remote protections, no current protection systems can help.”

Let me be clear: I have no data to indicate that the attack on Dyn is related to extortion, to Mirai or to any of the companies or individuals Madory referenced in his talk this week in Dallas. But Dyn is known for publishing detailed writeups on outages at other major Internet service providers. Here’s hoping the company does not deviate from that practice and soon publishes a postmortem on its own attack.

Update, 3:50 p.m. ET: Security firm Flashpoint is now reporting that they have seen indications that a Mirai-based botnet is indeed involved in the attack on Dyn today. Separately, I have heard from a trusted source who’s been tracking this activity and saw chatter in the cybercrime underground yesterday discussing a plan to attack Dyn.

Update, 10:22 a.m. ET: Dyn’s status page reports that all services are back to normal as of 13:20 UTC (9:20 a.m. ET). Fixed the link to Doug Madory’s talk on Youtube, to remove the URL shortener (which isn’t working because of this attack).

Update, 1:01 p.m. ET: Looks like the attacks on Dyn have resumed and this event is ongoing. This, from the Dyn status page:

This DDoS attack may also be impacting Dyn Managed DNS advanced services with possible delays in monitoring. Our Engineers are continuing to work on mitigating this issue.
Oct 21, 16:48 UTC
As of 15:52 UTC, we have begun monitoring and mitigating a DDoS attack against our Dyn Managed DNS infrastructure. Our Engineers are continuing to work on mitigating this issue.
Oct 21, 16:06 UTC
Top

jasper: NULL pointer dereference in jpc_tsfb_synthesize (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.

Another round of fuzzing on an updated version (1.900.5) revealed another NULL pointer access

The complete ASan output:

# imginfo -f $FILE
warning: trailing garbage in marker segment (14 bytes)
warning: not enough tile data (15 bytes)
warning: bad segmentation symbol
warning: bad segmentation symbol
ASAN:DEADLYSIGNAL
=================================================================
==7144==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f6d3c37d0b0 bp 0x7ffdc7407a90 sp 0x7ffdc7407a30 T0)
    #0 0x7f6d3c37d0af in jpc_tsfb_synthesize /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jpc/jpc_tsfb.c:152:4
    #1 0x7f6d3c2f5140 in jpc_dec_tiledecode /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jpc/jpc_dec.c:1068:3
    #2 0x7f6d3c2e5c40 in jpc_dec_process_sod /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jpc/jpc_dec.c:623:7
    #3 0x7f6d3c2ef294 in jpc_dec_decode /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jpc/jpc_dec.c:390:10
    #4 0x7f6d3c2ef294 in jpc_decode /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jpc/jpc_dec.c:254
    #5 0x7f6d3c2bd061 in jp2_decode /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jp2/jp2_dec.c:215:21
    #6 0x7f6d3c24df39 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/base/jas_image.c:380:16
    #7 0x4f1686 in main /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/appl/imginfo.c:188:16
    #8 0x7f6d3b35c61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                                                                                                        
    #9 0x418e68 in _init (/usr/bin/imginfo+0x418e68)                                                                                                                                                                                                                           

AddressSanitizer can not provide additional info.                                                                                                                                                                                                                              
SUMMARY: AddressSanitizer: SEGV /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jpc/jpc_tsfb.c:152:4 in jpc_tsfb_synthesize                                                                                                                           
==7144==ABORTING
Affected version:
1.900.5

Fixed version:
1.900.9

Commit fix:
https://github.com/mdadams/jasper/commit/2e82fa00466ae525339754bb3ab0a0474a31d4bd

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

CVE:
N/A

Timeline:
2016-10-19: bug discovered
2016-10-19: bug reported to upstream
2016-10-20: upstream released the patch and 1.900.9
2016-10-20: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

jasper: NULL pointer dereference in jpc_tsfb_synthesize (jpc_tsfb.c)

Top

imagemagick: memory allocation failure in AcquireMagickMemory (memory.c) (incomplete fix for CVE-2016-8862)

Postby ago via agostino's blog »

Description:
imagemagick is a software suite to create, edit, compose, or convert bitmap images.

Another round of fuzzing pointed out that the memory allocation failure I discovered is still reproducible in the 7.0.3.4 version.
As usual, the upstream security policy are enabled.

The interesting part of the ASan stacktrace(not full because is a copy past of the one in the previous post):

# identify $FILE
   #9 0x7f467fd11c67 in AcquireMagickMemory /tmp/portage/media-gfx/imagemagick-7.0.3.4/work/ImageMagick-7.0.3-4/MagickCore/memory.c:460:10
    #10 0x7f467fd11c67 in AcquireQuantumMemory /tmp/portage/media-gfx/imagemagick-7.0.3.4/work/ImageMagick-7.0.3-4/MagickCore/memory.c:533
    #11 0x7f4673379018 in ReadRLEImage /tmp/portage/media-gfx/imagemagick-7.0.3.4/work/ImageMagick-7.0.3-4/coders/rle.c:267:36
    #12 0x7f467faeca85 in ReadImage /tmp/portage/media-gfx/imagemagick-7.0.3.4/work/ImageMagick-7.0.3-4/MagickCore/constitute.c:496:13
    #13 0x7f467fff4def in ReadStream /tmp/portage/media-gfx/imagemagick-7.0.3.4/work/ImageMagick-7.0.3-4/MagickCore/stream.c:1012:9
    #14 0x7f467faeb69d in PingImage /tmp/portage/media-gfx/imagemagick-7.0.3.4/work/ImageMagick-7.0.3-4/MagickCore/constitute.c:226:9
    #15 0x7f467faebeae in PingImages /tmp/portage/media-gfx/imagemagick-7.0.3.4/work/ImageMagick-7.0.3-4/MagickCore/constitute.c:326:10
    #16 0x7f467f40f4da in IdentifyImageCommand /tmp/portage/media-gfx/imagemagick-7.0.3.4/work/ImageMagick-7.0.3-4/MagickWand/identify.c:319:18
    #17 0x7f467f48a844 in MagickCommandGenesis /tmp/portage/media-gfx/imagemagick-7.0.3.4/work/ImageMagick-7.0.3-4/MagickWand/mogrify.c:183:14
    #18 0x4f1fae in MagickMain /tmp/portage/media-gfx/imagemagick-7.0.3.4/work/ImageMagick-7.0.3-4/utilities/magick.c:145:10
    #19 0x4f1fae in main /tmp/portage/media-gfx/imagemagick-7.0.3.4/work/ImageMagick-7.0.3-4/utilities/magick.c:176
    #20 0x7f467e35d61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #21 0x4192a8 in _init (/usr/bin/magick+0x4192a8)
Affected version:
7.0.3.4

Fixed version:
N/A

Commit fix:


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

CVE:
CVE-2016-8866

Timeline:
2016-10-13: bug re-discovered
2016-10-13: bug re-reported to upstream
2016-10-20: blog post about the issue
2016-10-21: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

imagemagick: memory allocation failure in AcquireMagickMemory (memory.c) (incomplete fix for CVE-2016-8862)

Top

Spreading the DDoS Disease and Selling the Cure

Postby BrianKrebs via Krebs on Security »

Earlier this month a hacker released the source code for Mirai, a malware strain that was used to launch a historically large 620 Gbps denial-of-service attack against this site in September. That attack came in apparent retribution for a story here which directly preceded the arrest of two Israeli men for allegedly running an online attack for hire service called vDOS. Turns out, the site where the Mirai source code was leaked had some very interesting things in common with the place vDOS called home.

The domain name where the Mirai source code was originally placed for download — santasbigcandycane[dot]cx — is registered at the same domain name registrar that was used to register the now-defunct DDoS-for-hire service vdos-s[dot]com.

Normally, this would not be remarkable, since most domain registrars have thousands or millions of domains in their stable. But in this case it is interesting mainly because the registrar used by both domains — a company called namecentral.comhas apparently been used to register just 38 domains since its inception by its current owner in 2012, according to a historic WHOIS records gathered by domaintools.com (for the full list see this PDF).

What’s more, a cursory look at the other domains registered via namecentral.com since then reveals a number of other DDoS-for-hire services, also known as “booter” or “stresser” services.

It’s extremely odd that someone would take on the considerable cost and trouble of creating a domain name registrar just to register a few dozen domains. It costs $3,500 to apply to the Internet Corporation for Assigned Names and Numbers (ICANN) for a new registrar authority. The annual fee for being an ICANN-approved registrar is $4,000, and then there’s a $800 quarterly fee for smaller registrars. In short, domain name registrars generally need to register many thousands of new domains each year just to turn a profit.

Many of the remaining three dozen or so domains registered via Namecentral over the past few years are tied to vDOS. Before vDOS was taken offline it was massively hacked, and a copy of the user and attack database was shared with KrebsOnSecurity. From those records it was easy to tell which third-party booter services were using vDOS’s application programming interface (API), a software function that allowed them to essentially resell access to vDOS with their own white-labeled stresser.

And a number of those vDOS resellers were registered through Namecentral, including 83144692[dot].com — a DDoS-for-hire service marketed at Chinese customers. Another Namecentral domain — vstress.net — also was a vDOS reseller.

Other DDoS-for-hire domains registered through Namecentral include xboot[dot]net, xr8edstresser[dot]com, snowstresser[dot]com, ezstress[dot]com, exilestress[dot]com, diamondstresser[dot]net, dd0s[dot]pw, rebelsecurity[dot]net, and beststressers[dot]com.

WHO RUNS NAMECENTRAL?

Namecentral’s current owner is a 19-year-old California man by the name of Jesse Wu. Responding to questions emailed from KrebsOnSecurity, Wu said Namecentral’s policy on abuse was inspired by Cloudflare, the DDoS protection company that guards Namecentral and most of the above-mentioned DDoS-for-hire sites from attacks of the very kind they sell.

“I’m not sure (since registrations are automated) but I’m going to guess that the reason you’re interested in us is because some stories you’ve written in the past had domains registered on our service or otherwise used one of our services,” Wu wrote.

“We have a policy inspired by Cloudflare’s similar policy that we ourselves will remain content-neutral and in the support of an open Internet, we will almost never remove a registration or stop providing services, and furthermore we’ll take any effort to ensure that registrations cannot be influenced by anyone besides the actual registrant making a change themselves – even if such website makes us uncomfortable,” Wu said. “However, as a US based company, we are held to US laws, and so if we receive a valid court issued order to stop providing services to a client, or to turn over/disable a domain, we would happily comply with such order.”

Wu’s message continued:

“As of this email, we have never received such an order, we have never been contacted by any law enforcement agency, and we have never even received a legitimate, credible abuse report. We realize this policy might make us popular with ‘dangerous’ websites but even then, if we denied them services, simply not providing them services would not make such website stop existing, they would just have to find some other service provider/registrar or change domains more often. Our services themselves cannot be used for anything harmful – a domain is just a string of letters, and the rest of our services involve website/ddos protection/ecommerce security services designed to protect websites.”

Taking a page from Cloudflare, indeed. I’ve long taken Cloudflare to task for granting DDoS protection for countless DDoS-for-hire services, to no avail. I’ve maintained that Cloudflare has a blatant conflict of interest here, and that the DDoS-for-hire industry would quickly blast itself into oblivion because the proprietors of these attack services like nothing more than to turn their attack cannons on each other. Cloudflare has steadfastly maintained that picking and choosing who gets to use their network is a slippery slope that it will not venture toward.

Although Mr. Wu says he had nothing to do with the domains registered through Namecentral, public records filed elsewhere raise serious unanswered questions about that claim.

In my Sept. 8 story, Israeli Online Attack Service Earned $600,000 in Two Years, I explained that the hacked vDOS database indicated the service was run by two 18-year-old Israeli men. At some point, vDOS decided to protect all customer logins to the service with an extended validation (EV) SSL certificate. And for that, it needed to show it was tied to an actual corporate entity.

My investigation into those responsible for supporting vDOS began after I took a closer look at the SSL certificate that vDOS-S[dot]com used to encrypt customer logins. On May 12, 2015, Digicert.com issued an EV SSL certificate for vDOS, according to this record.

As we can see, whoever registered that EV cert did so using the business name VS NETWORK SERVICES LTD, and giving an address in the United Kingdom of 217 Blossomfield Rd., Solihull, West Midlands.

Who owns VS NETWORK SERVICES LTD? According this record from Companies House UK — an official ledger of corporations located in the United Kingdom — the director of the company was listed as one Thomas McGonagall. 

Records from Companies House UK on the firm responsible for registering vDOS’s SSL certificate.
This individual gave the same West Midlands address, stating that he was appointed to VS Network Services on May 12, 2015, and that his birthday was in May 1988. A search in Companies House for Thomas McGonagall shows that a person by that same name and address also was listed that very same day as a director for a company called REBELSECURITY LTD.

If we go back even further into the corporate history of this mysterious Mr. McGonagall we find that he was appointed director of NAMECENTRAL LTD on August 18, 2014. Mr. McGonagall’s birthday is listed as December 1995 in this record, and his address is given as 29 Wigorn Road, 29 Wigorn Road, Smethwick, West Midlands, United Kingdom, B67 5HL. Also on that same day, he was appointed to run EZSTRESS LTD, a company at the same Smethwick, West Midlands address.

Strangely enough, those company names correspond to other domains registered through Namecentral around the same time the companies were created, including rebelsecurity[dot]net, ezstress[dot]net.

Asked to explain the odd apparent corporate connections between Namecentral, vDOS, EZStress and Rebelsecurity, Wu chalked that up to an imposter or potential phishing attack.

“I’m not sure who that is, and we are not affiliated with Namecentral Ltd.,” he wrote. “I looked it up though and it seems like it is either closed or has never been active. From what you described it could be possible someone set up shell companies to try and get/resell EV certs (and someone’s failed attempt to set up a phishing site for us – thanks for the heads up).”

Interestingly, among the three dozen or so domains registered through Namecentral.com is “certificateavenue.com,” a site that until recently included nearly identical content as Namecentral’s home page and appears to be aimed at selling EV certs. Certificateavenue.com was responding as of early-October, but it is no longer online.

I also asked Wu why he chose to become a domain registrar when it appeared he had very few domains to justify the substantial annual costs of maintaining a registrar business.

“Like most other registrars, we register domains only as a value added service,” he replied via email. “We have more domains than that (not willing to say exactly how many) but primarily we make our money on our website/ddos protection/ecommerce protection.”

Now we were getting somewhere. Turns out, Wu isn’t really in the domain registrar business — not for the money, anyway. The real money, as his response suggests, is in selling DDoS protection against the very DDoS-for-hire services he is courting with his domain registration service.

Asked to reconcile his claim for having a 100 percent hands-off, automated domain registration system with the fact that Namecentral’s home page says the company doesn’t actually have a way to accept automated domain name registrations (like most normal domain registrars), Wu again had an answer.

“Our site says we only take referred registrations, meaning that at the moment we’re asking that another prior customer referred you to open a new account for our services, including if you’d like a reseller account,” he wrote.

CAUGHT IN A FIB?

I was willing to entertain the notion that perhaps Mr. Wu was in fact the target of a rather elaborate scam of some sort. That is, until I stumbled upon another company that was registered in the U.K. to Mr. McGonagall.

That other company —SIMPLIFYNT LTD — was registered by Mr. McGonagall on October 29, 2014. Turns out, almost the exact same information included in the original Web site registration records for Jesse Wu’s purchase of Namecentral.com was used for the domain simplifynt.com, which also was registered on Oct. 29, 2014. I initially missed this domain because it was not registered through Namecentral. If someone had phished Mr. Wu in this case, they had been very quick to the punch indeed.

In the simplyfynt.com domain registration records, Jesse Wu gave his email address as jesse@jjdev.ru. That domain is no longer online, but a cached copy of it at archive.org shows that it was once a Web development business. That cached page lists yet another contact email address: sales@jjdevelopments.org.

I ordered a reverse WHOIS lookup from domaintools.com on all historic Web site registration records that included the domain “jjdevelopments.org” anywhere in the records. The search returned 15 other domains, including several more apparent DDoS-for-hire domains such as twbooter69.com, twbooter3.com, ratemyddos.com and desoboot.com.

Among the oldest and most innocuous of those 15 domains was maplemystery.com, a fan site for a massively multiplayer online role-playing game (MMORPG) called Maple Story. Another historic record lookup ordered from domaintools.com shows that maplemystery.com was originally registered in 2009 to a “Denny Ng.” As it happens, Denny Ng is listed as the co-owner of the $1.6 million Walnut, Calif. home where Jesse until very recently lived with his mom Cindy Wu (Jesse is now a student at the University of California, San Diego).

WHO IS DATAWAGON?

Another domain of interest that was secured via Namecentral is datawagon.net. Registered by 19-year-old Christopher J. “CJ” Sculti Jr., Datawagon also bills itself as a DDoS mitigation firm. It appears Mr. Sculti built his DDoS protection empire out of his parents’ $2.6 million home in Rye, NY. He’s now a student at Clemson University, according to his Facebook page.

CJ Sculti Jr.’s Facebook profile photo. Sculti is on pictured on the right.
As I noted in my story DDoS Mitigation Firm Has a History of Hijacks, Sculti earned his 15 minutes of fame in 2015 when he lost a cybersquatting suit with Dominos Pizza after registering the domain dominos.pizza (another domain registered via Namecentral).

Around that time, Sculti contacted KrebsOnSecurity via Skype, asking if I’d be interested in writing about this cybersquatting dispute with Dominos. In that conversation, Sculti — apropos of nothing — admits to having just scanned the Internet for routers that were known to be protected by little more than the factory-default usernames and passwords.

Sculti goes on to brag that his scan revealed a quarter-million routers that were vulnerable, and that he then proceeded to upload some kind software to each vulnerable system. Here’s a snippet of that chat conversation, which is virtually one-sided.

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

21:38 CJ
yea

21:38 CJ
i’m surprised no one has looked into that yet

21:38 CJ
but

21:39 CJ
it’s a huge issue lol

21:39 CJ
that’s tons of bandwidth

21:39 CJ
that could be potentially used

21:39 CJ
in the wrong way

21:39 CJ
lol


Tons of bandwidth, indeed. The very next time I heard from Sculti was the same day I published the above-mentioned story about Datawagon’s relationship to BackConnect Inc., a company that admitted to hijacking 256 Internet addresses from vDOS’s hosting provider in Bulgaria — allegedly to defend itself against a monster attack allegedly launched by vDOS’s proprietors.

Sculti took issue with how he was portrayed in that report, and after a few terse words were exchanged, I blocked his Skype account from further communicating with mine. Less than an hour after that exchange, my Skype inbox was flooded with thousands of bogus contact requests from hacked or auto-created Skype accounts.

Less than six hours after that conversation, my site came under the biggest DDoS attack the Internet had ever witnessed at the time, an attack that experts have since traced back to a large botnet of IoT devices infected with Mirai.

As I wrote in the story that apparently incurred Sculti’s ire, Datawagon — like BackConnect — also has a history of hijacking broad swaths of Internet address space that do not belong to it. That listing came not long after Datawagon announced that it was the rightful owner of some 256 Internet addresses (1.3.3.0/24) that had long been dormant.

The Web address 1.3.3.7 currently does not respond to browser requests, but it previously routed to a page listing the core members of a hacker group calling itself the Money Team. Other sites also previously tied to that Internet address include numerous DDoS-for-hire services, such as nazistresser[dot]biz, exostress[dot]in, scriptkiddie[dot]eu, packeting[dot]eu, leet[dot]hu, booter[dot]in, vivostresser[dot]com, shockingbooter[dot]com and xboot[dot]info, among others.

Datawagon has earned a reputation on hacker forums as a “bulletproof” hosting provider — one that will essentially ignore abuse complaints from other providers and turn a blind eye to malicious activity perpetrated by its customers. In the screenshot below — taken from a thread on Hackforums where Datawagon was suggested as a reliable bulletproof hoster — the company is mentioned in the same vein as HostSailor, another bulletproof provider that has been the source of much badness (as well as legal threats against this author).



In yet another Hackforums discussion thread from June 2016 titled “VPS [virtual private servers] that allow DDoS scripts,” one user recommends Datawagon. “I use datawagon.net. They allow anything.”

Last year, Sculti formed a company in Florida along with a self-avowed spammer. Perhaps unsurprisingly, anti-spam group Spamhaus soon listed virtually all of Datawagon’s Internet address space as sources of spam.

Are either Mr. Wu or Mr. Sculti behind the Mirai botnet attacks? I cannot say. But I’d be willing to bet money that one or both of them knows who is. In any case, it would appear that both men may have hit upon a very lucrative business model. More to come.
Top

This week in vc4 (2016-10-18): X performance, DEQP, simulation

Postby Eric Anholt via anholt's lj »

The most visible change this week is a fix to Mesa for texture upload performance.  A user had reported that selection rectangles in LXDE's file manager were really slow.  I brought up sysprof, and it showed that we were doing uncached reads from the GPU in a situation that should have been entirely write-combined writes.

The bug was that when the size of the texture wasn't aligned to utiles, we were loading the previous contents into the temporary buffer before writing the new texture data in and uploading, even if the full texture was being updated.  I've fixed it to check for when the full texture is being uploaded, and not do the initial download.  This bug was getting it on almost any Cairo vector graphics operation with its Xlib backend, so hopefully this helps a lot of people's desktops.

I also worked on a cleanup of the simulator mode.  I use the closed source simulator regularly as part of my work -- it's fairly accurate to hardware behavior, and allows you to trace what's happening when things go wrong, all with the driver code running like "normal" for apps on my x86 desktop.

However, my simulator support is a little invasive to the driver, replacing vc4 ioctl calls with alternative ioctls to the i915 driver.  I started on a series to make vc4_simulator.c take plain VC4 ioctls and translate them, so that the simulator code is entirely contained.  The last step I think I have is figuring out which level to put the simulator's copying in and out of window system framebuffers at.

Last, I got DEQP's GLES2 tests up and running on Raspberry Pi.  These are approximately equivalent to the official conformance tests.  The initial results were quite good -- 18630/19098 (97.5%) passing when run in the piglit framework.  I found a couple of fixes to be made in glClear() support, one of which will affect all gallium drivers.  Of the remainder, there are a few tests that are failing due to test bugs (we expose extensions that allow features the tests don't expect), but most are failing in register allocation.  For the register allocation failures, I see a relatively quick fix that should reduce register pressure in loops.
Top

libwmf: memory allocation failure in wmf_malloc (api.c)

Postby ago via agostino's blog »

Description:
libwmf is a library for reading vector images in Microsøft’s native Windøws Metafile Format (WMF) and for either (a) displaying them in, e.g., an X window; or (b) converting them to more standard/open file formats such as, e.g., the W3C’s XML-based Scaleable Vector Graphic (SVG) format.

A fuzzing through imagemagick revealed a memory allocation failure. It was first reported to imagemagick developers(to double-check) which stated that the issue is in libwmf.
Since the libwmf project is dead the issue has not been reported elsewhere.

The complete ASan output:

# identify $FILE
==25497==ERROR: AddressSanitizer failed to allocate 0xfe769000 (4269182976) bytes of LargeMmapAllocator (error code: 12)                                                                                                                                                       
==25497==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-0x604000010000                                                                                                                                                                                                                                          
        0x604000010000-0x606000000000                                                                                                                                                                                                                                          
        0x606000000000-0x606000010000                                                                                                                                                                                                                                          
        0x606000010000-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-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-0x640000000000
        0x640000000000-0x640000003000
        0x7f7173b49000-0x7f7173b65000   /usr/lib64/libwmflite-0.2.so.7.0.1
        0x7f7173b65000-0x7f7173d64000   /usr/lib64/libwmflite-0.2.so.7.0.1
        0x7f7173d64000-0x7f7173d65000   /usr/lib64/libwmflite-0.2.so.7.0.1
        0x7f7173d65000-0x7f7173d66000   /usr/lib64/libwmflite-0.2.so.7.0.1
        0x7f7173d66000-0x7f7173d8c000   /usr/lib64/ImageMagick-7.0.3/modules-Q64HDRI/coders/wmf.so
        0x7f7173d8c000-0x7f7173f8b000   /usr/lib64/ImageMagick-7.0.3/modules-Q64HDRI/coders/wmf.so
        0x7f7173f8b000-0x7f7173f8c000   /usr/lib64/ImageMagick-7.0.3/modules-Q64HDRI/coders/wmf.so
        0x7f7173f8c000-0x7f7173f8e000   /usr/lib64/ImageMagick-7.0.3/modules-Q64HDRI/coders/wmf.so
        0x7f7173f8e000-0x7f717a600000   /usr/lib64/locale/locale-archive
        0x7f717a600000-0x7f717a700000
        0x7f717a800000-0x7f717a900000
        0x7f717a946000-0x7f717cc98000
        0x7f717cc98000-0x7f717ccbf000   /usr/lib64/libexpat.so.1.6.0
        0x7f717ccbf000-0x7f717cebe000   /usr/lib64/libexpat.so.1.6.0
        0x7f717cebe000-0x7f717cec1000   /usr/lib64/libexpat.so.1.6.0
        0x7f717cec1000-0x7f717cec2000   /usr/lib64/libexpat.so.1.6.0
        0x7f717cec2000-0x7f717cff7000   /usr/lib64/libglib-2.0.so.0.4600.2
        0x7f717cff7000-0x7f717d1f7000   /usr/lib64/libglib-2.0.so.0.4600.2
        0x7f717d1f7000-0x7f717d1f8000   /usr/lib64/libglib-2.0.so.0.4600.2
        0x7f717d1f8000-0x7f717d1f9000   /usr/lib64/libglib-2.0.so.0.4600.2
        0x7f717d1f9000-0x7f717d1fa000
        0x7f717d1fa000-0x7f717d203000   /usr/lib64/libltdl.so.7.3.1
        0x7f717d203000-0x7f717d402000   /usr/lib64/libltdl.so.7.3.1
        0x7f717d402000-0x7f717d403000   /usr/lib64/libltdl.so.7.3.1
        0x7f717d403000-0x7f717d404000   /usr/lib64/libltdl.so.7.3.1
        0x7f717d404000-0x7f717d419000   /lib64/libz.so.1.2.8
        0x7f717d419000-0x7f717d618000   /lib64/libz.so.1.2.8
        0x7f717d618000-0x7f717d619000   /lib64/libz.so.1.2.8
        0x7f717d619000-0x7f717d61a000   /lib64/libz.so.1.2.8
        0x7f717d61a000-0x7f717d629000   /lib64/libbz2.so.1.0.6
        0x7f717d629000-0x7f717d828000   /lib64/libbz2.so.1.0.6
        0x7f717d828000-0x7f717d829000   /lib64/libbz2.so.1.0.6
        0x7f717d829000-0x7f717d82a000   /lib64/libbz2.so.1.0.6
        0x7f717d82a000-0x7f717d8d1000   /usr/lib64/libfreetype.so.6.12.3
        0x7f717d8d1000-0x7f717dad1000   /usr/lib64/libfreetype.so.6.12.3
        0x7f717dad1000-0x7f717dad7000   /usr/lib64/libfreetype.so.6.12.3
        0x7f717dad7000-0x7f717dad8000   /usr/lib64/libfreetype.so.6.12.3
        0x7f717dad8000-0x7f717db13000   /usr/lib64/libfontconfig.so.1.8.0
        0x7f717db13000-0x7f717dd12000   /usr/lib64/libfontconfig.so.1.8.0
        0x7f717dd12000-0x7f717dd14000   /usr/lib64/libfontconfig.so.1.8.0
        0x7f717dd14000-0x7f717dd15000   /usr/lib64/libfontconfig.so.1.8.0
        0x7f717dd15000-0x7f717df0a000   /usr/lib64/libfftw3.so.3.4.4
        0x7f717df0a000-0x7f717e109000   /usr/lib64/libfftw3.so.3.4.4
        0x7f717e109000-0x7f717e11d000   /usr/lib64/libfftw3.so.3.4.4
        0x7f717e11d000-0x7f717e11e000   /usr/lib64/libfftw3.so.3.4.4
        0x7f717e11e000-0x7f717e12c000   /usr/lib64/liblqr-1.so.0.3.2
        0x7f717e12c000-0x7f717e32b000   /usr/lib64/liblqr-1.so.0.3.2
        0x7f717e32b000-0x7f717e32c000   /usr/lib64/liblqr-1.so.0.3.2
        0x7f717e32c000-0x7f717e32d000   /usr/lib64/liblqr-1.so.0.3.2
        0x7f717e32d000-0x7f717e380000   /usr/lib64/liblcms2.so.2.0.6
        0x7f717e380000-0x7f717e580000   /usr/lib64/liblcms2.so.2.0.6
        0x7f717e580000-0x7f717e581000   /usr/lib64/liblcms2.so.2.0.6
        0x7f717e581000-0x7f717e586000   /usr/lib64/liblcms2.so.2.0.6
        0x7f717e586000-0x7f717e719000   /lib64/libc-2.22.so
        0x7f717e719000-0x7f717e919000   /lib64/libc-2.22.so
        0x7f717e919000-0x7f717e91d000   /lib64/libc-2.22.so
        0x7f717e91d000-0x7f717e91f000   /lib64/libc-2.22.so
        0x7f717e91f000-0x7f717e923000
        0x7f717e923000-0x7f717e939000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7f717e939000-0x7f717eb38000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7f717eb38000-0x7f717eb39000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7f717eb39000-0x7f717eb3a000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7f717eb3a000-0x7f717eb40000   /lib64/librt-2.22.so
        0x7f717eb40000-0x7f717ed40000   /lib64/librt-2.22.so
        0x7f717ed40000-0x7f717ed41000   /lib64/librt-2.22.so
        0x7f717ed41000-0x7f717ed42000   /lib64/librt-2.22.so
        0x7f717ed42000-0x7f717ed59000   /lib64/libpthread-2.22.so
        0x7f717ed59000-0x7f717ef58000   /lib64/libpthread-2.22.so
        0x7f717ef58000-0x7f717ef59000   /lib64/libpthread-2.22.so
        0x7f717ef59000-0x7f717ef5a000   /lib64/libpthread-2.22.so
        0x7f717ef5a000-0x7f717ef5e000
        0x7f717ef5e000-0x7f717f05b000   /lib64/libm-2.22.so
        0x7f717f05b000-0x7f717f25a000   /lib64/libm-2.22.so
        0x7f717f25a000-0x7f717f25b000   /lib64/libm-2.22.so
        0x7f717f25b000-0x7f717f25c000   /lib64/libm-2.22.so
        0x7f717f25c000-0x7f717f25e000   /lib64/libdl-2.22.so
        0x7f717f25e000-0x7f717f45e000   /lib64/libdl-2.22.so
        0x7f717f45e000-0x7f717f45f000   /lib64/libdl-2.22.so
        0x7f717f45f000-0x7f717f460000   /lib64/libdl-2.22.so
        0x7f717f460000-0x7f717f926000   /usr/lib64/libMagickWand-7.Q64HDRI.so.0.0.0
        0x7f717f926000-0x7f717fb25000   /usr/lib64/libMagickWand-7.Q64HDRI.so.0.0.0
        0x7f717fb25000-0x7f717fb3a000   /usr/lib64/libMagickWand-7.Q64HDRI.so.0.0.0
        0x7f717fb3a000-0x7f717fb7c000   /usr/lib64/libMagickWand-7.Q64HDRI.so.0.0.0
        0x7f717fb7c000-0x7f718070f000   /usr/lib64/libMagickCore-7.Q64HDRI.so.0.0.0
        0x7f718070f000-0x7f718090e000   /usr/lib64/libMagickCore-7.Q64HDRI.so.0.0.0
        0x7f718090e000-0x7f7180947000   /usr/lib64/libMagickCore-7.Q64HDRI.so.0.0.0
        0x7f7180947000-0x7f71809b9000   /usr/lib64/libMagickCore-7.Q64HDRI.so.0.0.0
        0x7f71809b9000-0x7f71809bc000
        0x7f71809bc000-0x7f71809de000   /lib64/ld-2.22.so
        0x7f7180a36000-0x7f7180b04000
        0x7f7180b04000-0x7f7180b27000   /usr/share/locale/it/LC_MESSAGES/libc.mo
        0x7f7180b27000-0x7f7180bd0000
        0x7f7180bd0000-0x7f7180bdd000
        0x7f7180bdd000-0x7f7180bde000   /lib64/ld-2.22.so
        0x7f7180bde000-0x7f7180bdf000   /lib64/ld-2.22.so
        0x7f7180bdf000-0x7f7180be0000
        0x7ffc0ab5e000-0x7ffc0ab7f000   [stack]
        0x7ffc0abdd000-0x7ffc0abdf000   [vvar]
        0x7ffc0abdf000-0x7ffc0abe1000   [vdso]
        0xffffffffff600000-0xffffffffff601000   [vsyscall]
==25497==End of process memory map.
==25497==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 0x42208f 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 0x42208f 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 0x42208f 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 0x42208f 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 0x4c0661 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 0x7f7173b4d337 in wmf_malloc /tmp/portage/media-libs/libwmf-0.2.8.4-r6/work/libwmf-0.2.8.4/src/api.c:482
    #10 0x7f7173b5d2f8 in wmf_scan /tmp/portage/media-libs/libwmf-0.2.8.4-r6/work/libwmf-0.2.8.4/src/player.c:143
    #11 0x7f7173d6dcf7 in ReadWMFImage /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/coders/wmf.c:2675:13
    #12 0x7f717fde7b12 in ReadImage /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/constitute.c:496:13
    #13 0x7f718057f406 in ReadStream /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/stream.c:1012:9
    #14 0x7f717fde65ca in PingImage /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/constitute.c:226:9
    #15 0x7f717fde6e25 in PingImages /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/constitute.c:326:10
    #16 0x7f717f66c4c3 in IdentifyImageCommand /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickWand/identify.c:319:18
    #17 0x7f717f70226a in MagickCommandGenesis /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickWand/mogrify.c:183:14
    #18 0x4f1fb5 in MagickMain /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/utilities/magick.c:145:10
    #19 0x4f1fb5 in main /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/utilities/magick.c:176
    #20 0x7f717e5a661f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #21 0x419138 in _init (/usr/bin/magick+0x419138)
Affected version:
0.2.8.4

Fixed version:
N/A

Commit fix:
N/A

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

CVE:
CVE-2016-9011

Timeline:
2016-09-14: bug discovered
2016-10-18: blog post about the issue
2016-10-25: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libwmf: memory allocation failure in wmf_malloc (api.c)

Top

snzip: memory allocation failure in work_buffer_resize (snzip.c)

Postby ago via agostino's blog »

Description:
snzip is a compression/decompression tool based on snappy.

A fuzzing revealed a memory allocation failure.

The complete ASan output:

# snzip -d $FILE
Ȥ�==12351==WARNING: AddressSanitizer failed to allocate 0xffffffffc8617364 bytes
==12351==AddressSanitizer's allocator is terminating the process instead of returning 0
==12351==If you don't like this behavior set allocator_may_return_null=1
==12351==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 0x4ca7ed 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 0x4d1323 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 0x4cf076 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 0x424896 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 0x424896 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 0x4205bd in __asan::Allocator::Reallocate(void*, 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:539                                                      
    #6 0x4205bd in __asan::asan_realloc(void*, 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:732                                                               
    #7 0x4c1231 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 0x4fe72c in work_buffer_resize /tmp/portage/app-arch/snzip-1.0.3/work/snzip-1.0.3/snzip.c:584:13                                                                                                                                                                        
    #9 0x51667b in snappy_java_uncompress /tmp/portage/app-arch/snzip-1.0.3/work/snzip-1.0.3/snappy-java-format.c:193:7                                                                                                                                                        
    #10 0x4f68ea in main /tmp/portage/app-arch/snzip-1.0.3/work/snzip-1.0.3/snzip.c:401:11                                                                                                                                                                                     
    #11 0x7fcbabbd261f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                                                                                                       
    #12 0x419988 in _init (/usr/bin/snzip+0x419988)
Affected version:
1.0.3

Fixed version:
N/A

Commit fix:
N/A

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

Timeline:
2016-10-13: bug discovered
2016-10-13: bug reported to upstream
2016-10-18: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

snzip: memory allocation failure in work_buffer_resize (snzip.c)

Top

jasper: two NULL pointer dereference in bmp_getdata (bmp_dec.c) (Incomplete fix for CVE-2016-8690)

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 on an updated version (1.900.5) revealed that the previous issues, reported as CVE-2016-8690, are unfixed.

The complete ASan output:

# imginfo -f $FILE
THE BMP FORMAT IS NOT FULLY SUPPORTED!                                                                                                                                                                                                                                         
THAT IS, THE JASPER SOFTWARE CANNOT DECODE ALL TYPES OF BMP DATA.                                                                                                                                                                                                              
IF YOU HAVE ANY PROBLEMS, PLEASE TRY CONVERTING YOUR IMAGE DATA                                                                                                                                                                                                                
TO THE PNM FORMAT, AND USING THIS FORMAT INSTEAD.                                                                                                                                                                                                                              
skipping unknown data in BMP file                                                                                                                                                                                                                                              
ASAN:DEADLYSIGNAL                                                                                                                                                                                                                                                              
=================================================================                                                                                                                                                                                                              
==19659==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f90527a18fe bp 0x7ffcfacc8070 sp 0x7ffcfacc7ee0 T0)
    #0 0x7f90527a18fd in bmp_getdata /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/bmp/bmp_dec.c:394:5
    #1 0x7f90527a18fd in bmp_decode /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/bmp/bmp_dec.c:201
    #2 0x7f9052748f39 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/base/jas_image.c:380:16
    #3 0x4f1686 in main /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/appl/imginfo.c:188:16
    #4 0x7f905185761f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #5 0x418e68 in _init (/usr/bin/imginfo+0x418e68)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/bmp/bmp_dec.c:394:5 in bmp_getdata
==19659==ABORTING

# imginfo -f $FILE
THE BMP FORMAT IS NOT FULLY SUPPORTED!
THAT IS, THE JASPER SOFTWARE CANNOT DECODE ALL TYPES OF BMP DATA.
IF YOU HAVE ANY PROBLEMS, PLEASE TRY CONVERTING YOUR IMAGE DATA
TO THE PNM FORMAT, AND USING THIS FORMAT INSTEAD.
ASAN:DEADLYSIGNAL
=================================================================
==11248==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f888b2f5a44 bp 0x7ffea5b3b070 sp 0x7ffea5b3aee0 T0)
    #0 0x7f888b2f5a43 in bmp_getdata /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/bmp/bmp_dec.c:398:5
    #1 0x7f888b2f5a43 in bmp_decode /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/bmp/bmp_dec.c:201
    #2 0x7f888b29cf39 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/base/jas_image.c:380:16
    #3 0x4f1686 in main /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/appl/imginfo.c:188:16
    #4 0x7f888a3ab61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #5 0x418e68 in _init (/usr/bin/imginfo+0x418e68)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/bmp/bmp_dec.c:398:5 in bmp_getdata
==11248==ABORTING
Affected version:
1.900.5

Fixed version:
1.900.9

Commit fix:
https://github.com/mdadams/jasper/commit/5d66894d2313e3f3469f19066e149e08ff076698

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

CVE:
CVE-2016-8884
CVE-2016-8885

Timeline:
2016-10-17: bug discovered
2016-10-17: bug reported to upstream
2016-10-18: blog post about the issue
2016-10-20: upstream released a pathc and 1.900.9
2016-10-23: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

jasper: two NULL pointer dereference in bmp_getdata (bmp_dec.c) (Incomplete fix for CVE-2016-8690)

Top

jasper: memory allocation failure in jas_malloc (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.

Another round of fuzzing on an updated version (1.900.5) revealed a memory allocation failure.

The complete ASan output:

# imginfo -f $FILE
THE BMP FORMAT IS NOT FULLY SUPPORTED!                                                                                                                                                                                                                                         
THAT IS, THE JASPER SOFTWARE CANNOT DECODE ALL TYPES OF BMP DATA.                                                                                                                                                                                                              
IF YOU HAVE ANY PROBLEMS, PLEASE TRY CONVERTING YOUR IMAGE DATA                                                                                                                                                                                                                
TO THE PNM FORMAT, AND USING THIS FORMAT INSTEAD.                                                                                                                                                                                                                              
==18943==ERROR: AddressSanitizer failed to allocate 0x1000002000 (68719484928) bytes of LargeMmapAllocator (error code: 12)                                                                                                                                                    
==18943==Process memory map follows:                                                                                                                                                                                                                                           
        0x000000400000-0x000000520000   /usr/bin/imginfo                                                                                                                                                                                                                       
        0x00000071f000-0x000000720000   /usr/bin/imginfo                                                                                                                                                                                                                       
        0x000000720000-0x000000724000   /usr/bin/imginfo                                                                                                                                                                                                                       
        0x000000724000-0x0000013a6000                                                                                                                                                                                                                                          
        0x00007fff7000-0x00008fff7000                                                                                                                                                                                                                                          
        0x00008fff7000-0x02008fff7000                                                                                                                                                                                                                                          
        0x02008fff7000-0x10007fff8000                                                                                                                                                                                                                                          
        0x600000000000-0x602000000000                                                                                                                                                                                                                                          
        0x602000000000-0x602000010000                                                                                                                                                                                                                                          
        0x602000010000-0x603000000000                                                                                                                                                                                                                                          
        0x603000000000-0x603000010000                                                                                                                                                                                                                                          
        0x603000010000-0x604000000000                                                                                                                                                                                                                                          
        0x604000000000-0x604000010000                                                                                                                                                                                                                                          
        0x604000010000-0x606000000000                                                                                                                                                                                                                                          
        0x606000000000-0x606000010000                                                                                                                                                                                                                                          
        0x606000010000-0x60b000000000                                                                                                                                                                                                                                          
        0x60b000000000-0x60b000010000                                                                                                                                                                                                                                          
        0x60b000010000-0x619000000000                                                                                                                                                                                                                                          
        0x619000000000-0x619000020000                                                                                                                                                                                                                                          
        0x619000020000-0x625000000000                                                                                                                                                                                                                                          
        0x625000000000-0x625000020000                                                                                                                                                                                                                                          
        0x625000020000-0x640000000000                                                                                                                                                                                                                                          
        0x640000000000-0x640000003000                                                                                                                                                                                                                                          
        0x7f4f00738000-0x7f4f03593000                                                                                                                                                                                                                                          
        0x7f4f03593000-0x7f4f035fc000   /usr/lib64/libjpeg.so.62.2.0                                                                                                                                                                                                           
        0x7f4f035fc000-0x7f4f037fb000   /usr/lib64/libjpeg.so.62.2.0                                                                                                                                                                                                           
        0x7f4f037fb000-0x7f4f037fc000   /usr/lib64/libjpeg.so.62.2.0                                                                                                                                                                                                           
        0x7f4f037fc000-0x7f4f037fd000   /usr/lib64/libjpeg.so.62.2.0                                                                                                                                                                                                           
        0x7f4f037fd000-0x7f4f03990000   /lib64/libc-2.22.so                                                                                                                                                                                                                    
        0x7f4f03990000-0x7f4f03b90000   /lib64/libc-2.22.so                                                                                                                                                                                                                    
        0x7f4f03b90000-0x7f4f03b94000   /lib64/libc-2.22.so                                                                                                                                                                                                                    
        0x7f4f03b94000-0x7f4f03b96000   /lib64/libc-2.22.so                                                                                                                                                                                                                    
        0x7f4f03b96000-0x7f4f03b9a000                                                                                                                                                                                                                                          
        0x7f4f03b9a000-0x7f4f03bb0000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1                                                                                                                                                                                 
        0x7f4f03bb0000-0x7f4f03daf000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1                                                                                                                                                                                 
        0x7f4f03daf000-0x7f4f03db0000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1                                                                                                                                                                                 
        0x7f4f03db0000-0x7f4f03db1000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1                                                                                                                                                                                 
        0x7f4f03db1000-0x7f4f03db3000   /lib64/libdl-2.22.so
        0x7f4f03db3000-0x7f4f03fb3000   /lib64/libdl-2.22.so
        0x7f4f03fb3000-0x7f4f03fb4000   /lib64/libdl-2.22.so
        0x7f4f03fb4000-0x7f4f03fb5000   /lib64/libdl-2.22.so
        0x7f4f03fb5000-0x7f4f03fbb000   /lib64/librt-2.22.so
        0x7f4f03fbb000-0x7f4f041bb000   /lib64/librt-2.22.so
        0x7f4f041bb000-0x7f4f041bc000   /lib64/librt-2.22.so
        0x7f4f041bc000-0x7f4f041bd000   /lib64/librt-2.22.so
        0x7f4f041bd000-0x7f4f041d4000   /lib64/libpthread-2.22.so
        0x7f4f041d4000-0x7f4f043d3000   /lib64/libpthread-2.22.so
        0x7f4f043d3000-0x7f4f043d4000   /lib64/libpthread-2.22.so
        0x7f4f043d4000-0x7f4f043d5000   /lib64/libpthread-2.22.so
        0x7f4f043d5000-0x7f4f043d9000
        0x7f4f043d9000-0x7f4f044d6000   /lib64/libm-2.22.so
        0x7f4f044d6000-0x7f4f046d5000   /lib64/libm-2.22.so
        0x7f4f046d5000-0x7f4f046d6000   /lib64/libm-2.22.so
        0x7f4f046d6000-0x7f4f046d7000   /lib64/libm-2.22.so
        0x7f4f046d7000-0x7f4f04891000   /usr/lib64/libjasper.so.1.0.0
        0x7f4f04891000-0x7f4f04a90000   /usr/lib64/libjasper.so.1.0.0
        0x7f4f04a90000-0x7f4f04a94000   /usr/lib64/libjasper.so.1.0.0
        0x7f4f04a94000-0x7f4f04aa3000   /usr/lib64/libjasper.so.1.0.0
        0x7f4f04aa3000-0x7f4f04aac000
        0x7f4f04aac000-0x7f4f04ace000   /lib64/ld-2.22.so
        0x7f4f04c67000-0x7f4f04cc2000
        0x7f4f04cc2000-0x7f4f04ccd000
        0x7f4f04ccd000-0x7f4f04cce000   /lib64/ld-2.22.so
        0x7f4f04cce000-0x7f4f04ccf000   /lib64/ld-2.22.so
        0x7f4f04ccf000-0x7f4f04cd0000
        0x7ffeaeaca000-0x7ffeaeaeb000   [stack]
        0x7ffeaeb8a000-0x7ffeaeb8c000   [vvar]
        0x7ffeaeb8c000-0x7ffeaeb8e000   [vdso]
        0xffffffffff600000-0xffffffffff601000   [vsyscall]
==18943==End of process memory map.
==18943==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 0x4c9ccd 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 0x4d0803 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 0x4d09f1 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 0x4d9a2a 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 0x421dbf 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 0x421dbf 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 0x421dbf 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 0x421dbf 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 0x4c0391 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 0x7f4f0474e170 in jas_malloc /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/base/jas_malloc.c:117:9
    #10 0x7f4f0474e170 in jas_alloc2 /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/base/jas_malloc.c:141
    #11 0x7f4f04764b4f in bmp_getinfo /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/bmp/bmp_dec.c:297:25
    #12 0x7f4f04764b4f in bmp_decode /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/bmp/bmp_dec.c:132
    #13 0x7f4f0470ef39 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/base/jas_image.c:380:16
    #14 0x4f1686 in main /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/appl/imginfo.c:188:16
    #15 0x7f4f0381d61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #16 0x418e68 in _init (/usr/bin/imginfo+0x418e68)
Affected version:
1.900.5

Fixed version:
N/A

Commit fix:
N/A

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

CVE:
CVE-2016-8886

Timeline:
2016-10-17: bug discovered
2016-10-17: bug reported to upstream
2016-10-18: blog post about the issue
2016-10-23: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

jasper: memory allocation failure in jas_malloc (jas_malloc.c)

Top

jasper: NULL pointer dereference in jp2_colr_destroy (jp2_cod.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 on an updated version (1.900.5) revealed a NULL pointer access in jp2_colr_destroy

The complete ASan output:

# imginfo -f $FILE
cannot copy box data                                                                                                                                                                                                                                                           
ASAN:DEADLYSIGNAL                                                                                                                                                                                                                                                              
=================================================================                                                                                                                                                                                                              
==19664==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000041defd bp 0xbebebebebebebebe sp 0x7ffc50768570 T0)                                                                                                                                        
    #0 0x41defc in atomic_compare_exchange_strong /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang.h:81                                                      
    #1 0x41defc in __asan::Allocator::AtomicallySetQuarantineFlag(__asan::AsanChunk*, void*, __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:465                                
    #2 0x41defc in __asan::Allocator::Deallocate(void*, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:525                                   
    #3 0x41defc in __asan::asan_free(void*, __sanitizer::BufferedStackTrace*, __asan::AllocType) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:709                                                              
    #4 0x4c008c 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:41                                                                                                                                     
    #5 0x7f8dcb5bc940 in jp2_colr_destroy /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jp2/jp2_cod.c:443:3                                                                                                                                         
    #6 0x7f8dcb5c1f69 in jp2_box_destroy /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jp2/jp2_cod.c:211:3                                                                                                                                          
    #7 0x7f8dcb5c1f69 in jp2_box_get /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jp2/jp2_cod.c:307                                                                                                                                                
    #8 0x7f8dcb5c5dc0 in jp2_decode /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jp2/jp2_dec.c:156:16                                                                                                                                              
    #9 0x7f8dcb556f39 in jas_image_decode /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/base/jas_image.c:380:16                                                                                                                                     
    #10 0x4f1686 in main /tmp/portage/media-libs/jasper-1.900.5/work/jasper-1.900.5/src/appl/imginfo.c:188:16                                                                                                                                                                  
    #11 0x7f8dca66561f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                                                                                                       
    #12 0x418e68 in _init (/usr/bin/imginfo+0x418e68)                                                                                                                                                                                                                          

AddressSanitizer can not provide additional info.                                                                                                                                                                                                                              
SUMMARY: AddressSanitizer: SEGV /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang.h:81 in atomic_compare_exchange_strong                                      
==19664==ABORTING
Affected version:
1.900.5

Fixed version:
1.900.10

Commit fix:
https://github.com/mdadams/jasper/commit/e24bdc716c3327b067c551bc6cfb97fd2370358d

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

CVE:
CVE-2016-8887

Timeline:
2016-10-17: bug discovered
2016-10-17: bug reported to upstream
2016-10-18: blog post about the issue
2016-10-21: upstream released a patch
2016-10-23: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

jasper: NULL pointer dereference in jp2_colr_destroy (jp2_cod.c)

Top

imagemagick: memory allocation failure in AcquireMagickMemory (memory.c)

Postby ago via agostino's blog »

Description:
imagemagick is a software suite to create, edit, compose, or convert bitmap images.

A fuzzing with the upstream security policy enabled revealed a memory allocation failure.

The complete ASan output:

# identify $FILE
==14275==ERROR: AddressSanitizer failed to allocate 0x99ad49000 (41252327424) bytes of LargeMmapAllocator (error code: 12)
==14275==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-0x604000010000
        0x604000010000-0x606000000000
        0x606000000000-0x606000010000
        0x606000010000-0x607000000000
        0x607000000000-0x607000010000
        0x607000010000-0x608000000000
        0x608000000000-0x608000010000
        0x608000010000-0x60a000000000
        0x60a000000000-0x60a000020000
        0x60a000020000-0x60b000000000
        0x60b000000000-0x60b000010000
        0x60b000010000-0x60c000000000
        0x60c000000000-0x60c000010000
        0x60c000010000-0x60e000000000
        0x60e000000000-0x60e000010000
        0x60e000010000-0x60f000000000
        0x60f000000000-0x60f000010000
        0x60f000010000-0x610000000000
        0x610000000000-0x610000010000
        0x610000010000-0x611000000000
        0x611000000000-0x611000010000
        0x611000010000-0x612000000000
        0x612000000000-0x612000010000
        0x612000010000-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-0x640000000000
        0x640000000000-0x640000003000
        0x7fe564f76000-0x7fe564f8d000   /usr/lib64/ImageMagick-7.0.3/modules-Q64HDRI/coders/pcx.so
        0x7fe564f8d000-0x7fe56518c000   /usr/lib64/ImageMagick-7.0.3/modules-Q64HDRI/coders/pcx.so
        0x7fe56518c000-0x7fe56518d000   /usr/lib64/ImageMagick-7.0.3/modules-Q64HDRI/coders/pcx.so
        0x7fe56518d000-0x7fe56518e000   /usr/lib64/ImageMagick-7.0.3/modules-Q64HDRI/coders/pcx.so
        0x7fe56518e000-0x7fe56b800000   /usr/lib64/locale/locale-archive
        0x7fe56b800000-0x7fe56b900000
        0x7fe56ba00000-0x7fe56bb00000
        0x7fe56bbe6000-0x7fe56df38000
        0x7fe56df38000-0x7fe56df5f000   /usr/lib64/libexpat.so.1.6.0
        0x7fe56df5f000-0x7fe56e15e000   /usr/lib64/libexpat.so.1.6.0
        0x7fe56e15e000-0x7fe56e161000   /usr/lib64/libexpat.so.1.6.0
        0x7fe56e161000-0x7fe56e162000   /usr/lib64/libexpat.so.1.6.0
        0x7fe56e162000-0x7fe56e297000   /usr/lib64/libglib-2.0.so.0.4600.2
        0x7fe56e297000-0x7fe56e497000   /usr/lib64/libglib-2.0.so.0.4600.2
        0x7fe56e497000-0x7fe56e498000   /usr/lib64/libglib-2.0.so.0.4600.2
        0x7fe56e498000-0x7fe56e499000   /usr/lib64/libglib-2.0.so.0.4600.2
        0x7fe56e499000-0x7fe56e49a000
        0x7fe56e49a000-0x7fe56e4a3000   /usr/lib64/libltdl.so.7.3.1
        0x7fe56e4a3000-0x7fe56e6a2000   /usr/lib64/libltdl.so.7.3.1
        0x7fe56e6a2000-0x7fe56e6a3000   /usr/lib64/libltdl.so.7.3.1
        0x7fe56e6a3000-0x7fe56e6a4000   /usr/lib64/libltdl.so.7.3.1
        0x7fe56e6a4000-0x7fe56e6b9000   /lib64/libz.so.1.2.8
        0x7fe56e6b9000-0x7fe56e8b8000   /lib64/libz.so.1.2.8
        0x7fe56e8b8000-0x7fe56e8b9000   /lib64/libz.so.1.2.8
        0x7fe56e8b9000-0x7fe56e8ba000   /lib64/libz.so.1.2.8
        0x7fe56e8ba000-0x7fe56e8c9000   /lib64/libbz2.so.1.0.6
        0x7fe56e8c9000-0x7fe56eac8000   /lib64/libbz2.so.1.0.6
        0x7fe56eac8000-0x7fe56eac9000   /lib64/libbz2.so.1.0.6
        0x7fe56eac9000-0x7fe56eaca000   /lib64/libbz2.so.1.0.6
        0x7fe56eaca000-0x7fe56eb71000   /usr/lib64/libfreetype.so.6.12.3
        0x7fe56eb71000-0x7fe56ed71000   /usr/lib64/libfreetype.so.6.12.3
        0x7fe56ed71000-0x7fe56ed77000   /usr/lib64/libfreetype.so.6.12.3
        0x7fe56ed77000-0x7fe56ed78000   /usr/lib64/libfreetype.so.6.12.3
        0x7fe56ed78000-0x7fe56edb3000   /usr/lib64/libfontconfig.so.1.8.0
        0x7fe56edb3000-0x7fe56efb2000   /usr/lib64/libfontconfig.so.1.8.0
        0x7fe56efb2000-0x7fe56efb4000   /usr/lib64/libfontconfig.so.1.8.0
        0x7fe56efb4000-0x7fe56efb5000   /usr/lib64/libfontconfig.so.1.8.0
        0x7fe56efb5000-0x7fe56f1aa000   /usr/lib64/libfftw3.so.3.4.4
        0x7fe56f1aa000-0x7fe56f3a9000   /usr/lib64/libfftw3.so.3.4.4
        0x7fe56f3a9000-0x7fe56f3bd000   /usr/lib64/libfftw3.so.3.4.4
        0x7fe56f3bd000-0x7fe56f3be000   /usr/lib64/libfftw3.so.3.4.4
        0x7fe56f3be000-0x7fe56f3cc000   /usr/lib64/liblqr-1.so.0.3.2
        0x7fe56f3cc000-0x7fe56f5cb000   /usr/lib64/liblqr-1.so.0.3.2
        0x7fe56f5cb000-0x7fe56f5cc000   /usr/lib64/liblqr-1.so.0.3.2
        0x7fe56f5cc000-0x7fe56f5cd000   /usr/lib64/liblqr-1.so.0.3.2
        0x7fe56f5cd000-0x7fe56f620000   /usr/lib64/liblcms2.so.2.0.6
        0x7fe56f620000-0x7fe56f820000   /usr/lib64/liblcms2.so.2.0.6
        0x7fe56f820000-0x7fe56f821000   /usr/lib64/liblcms2.so.2.0.6
        0x7fe56f821000-0x7fe56f826000   /usr/lib64/liblcms2.so.2.0.6
        0x7fe56f826000-0x7fe56f9b9000   /lib64/libc-2.22.so
        0x7fe56f9b9000-0x7fe56fbb9000   /lib64/libc-2.22.so
        0x7fe56fbb9000-0x7fe56fbbd000   /lib64/libc-2.22.so
        0x7fe56fbbd000-0x7fe56fbbf000   /lib64/libc-2.22.so
        0x7fe56fbbf000-0x7fe56fbc3000
        0x7fe56fbc3000-0x7fe56fbd9000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7fe56fbd9000-0x7fe56fdd8000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7fe56fdd8000-0x7fe56fdd9000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7fe56fdd9000-0x7fe56fdda000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7fe56fdda000-0x7fe56fde0000   /lib64/librt-2.22.so
        0x7fe56fde0000-0x7fe56ffe0000   /lib64/librt-2.22.so
        0x7fe56ffe0000-0x7fe56ffe1000   /lib64/librt-2.22.so
        0x7fe56ffe1000-0x7fe56ffe2000   /lib64/librt-2.22.so
        0x7fe56ffe2000-0x7fe56fff9000   /lib64/libpthread-2.22.so
        0x7fe56fff9000-0x7fe5701f8000   /lib64/libpthread-2.22.so
        0x7fe5701f8000-0x7fe5701f9000   /lib64/libpthread-2.22.so
        0x7fe5701f9000-0x7fe5701fa000   /lib64/libpthread-2.22.so
        0x7fe5701fa000-0x7fe5701fe000
        0x7fe5701fe000-0x7fe5702fb000   /lib64/libm-2.22.so
        0x7fe5702fb000-0x7fe5704fa000   /lib64/libm-2.22.so
        0x7fe5704fa000-0x7fe5704fb000   /lib64/libm-2.22.so
        0x7fe5704fb000-0x7fe5704fc000   /lib64/libm-2.22.so
        0x7fe5704fc000-0x7fe5704fe000   /lib64/libdl-2.22.so
        0x7fe5704fe000-0x7fe5706fe000   /lib64/libdl-2.22.so
        0x7fe5706fe000-0x7fe5706ff000   /lib64/libdl-2.22.so
        0x7fe5706ff000-0x7fe570700000   /lib64/libdl-2.22.so
        0x7fe570700000-0x7fe570bc6000   /usr/lib64/libMagickWand-7.Q64HDRI.so.0.0.0
        0x7fe570bc6000-0x7fe570dc5000   /usr/lib64/libMagickWand-7.Q64HDRI.so.0.0.0
        0x7fe570dc5000-0x7fe570dda000   /usr/lib64/libMagickWand-7.Q64HDRI.so.0.0.0
        0x7fe570dda000-0x7fe570e1c000   /usr/lib64/libMagickWand-7.Q64HDRI.so.0.0.0
        0x7fe570e1c000-0x7fe5719af000   /usr/lib64/libMagickCore-7.Q64HDRI.so.0.0.0
        0x7fe5719af000-0x7fe571bae000   /usr/lib64/libMagickCore-7.Q64HDRI.so.0.0.0
        0x7fe571bae000-0x7fe571be7000   /usr/lib64/libMagickCore-7.Q64HDRI.so.0.0.0
        0x7fe571be7000-0x7fe571c59000   /usr/lib64/libMagickCore-7.Q64HDRI.so.0.0.0
        0x7fe571c59000-0x7fe571c5c000
        0x7fe571c5c000-0x7fe571c7e000   /lib64/ld-2.22.so
        0x7fe571cf9000-0x7fe571da4000
        0x7fe571da4000-0x7fe571dc7000   /usr/share/locale/it/LC_MESSAGES/libc.mo
        0x7fe571dc7000-0x7fe571e70000
        0x7fe571e70000-0x7fe571e7d000
        0x7fe571e7d000-0x7fe571e7e000   /lib64/ld-2.22.so
        0x7fe571e7e000-0x7fe571e7f000   /lib64/ld-2.22.so
        0x7fe571e7f000-0x7fe571e80000
        0x7ffddcca3000-0x7ffddccc4000   [stack]
        0x7ffddcd4d000-0x7ffddcd4f000   [vvar]
        0x7ffddcd4f000-0x7ffddcd51000   [vdso]
        0xffffffffff600000-0xffffffffff601000   [vsyscall]
==14275==End of process memory map.
==14275==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 0x42208f 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 0x42208f 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 0x42208f 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 0x42208f 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 0x4c0661 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 0x7fe5713b3b3b in AcquireMagickMemory /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/memory.c:460:10
    #10 0x7fe5713b3b3b in AcquireVirtualMemory /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/memory.c:642
    #11 0x7fe564f7af95 in ReadPCXImage /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/coders/pcx.c:400:16
    #12 0x7fe571087b12 in ReadImage /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/constitute.c:496:13
    #13 0x7fe57181f406 in ReadStream /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/stream.c:1012:9
    #14 0x7fe5710865ca in PingImage /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/constitute.c:226:9
    #15 0x7fe571086e25 in PingImages /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickCore/constitute.c:326:10
    #16 0x7fe57090c4c3 in IdentifyImageCommand /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickWand/identify.c:319:18
    #17 0x7fe5709a226a in MagickCommandGenesis /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/MagickWand/mogrify.c:183:14
    #18 0x4f1fb5 in MagickMain /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/utilities/magick.c:145:10
    #19 0x4f1fb5 in main /tmp/portage/media-gfx/imagemagick-7.0.3.0/work/ImageMagick-7.0.3-0/utilities/magick.c:176
    #20 0x7fe56f84661f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #21 0x419138 in _init (/usr/bin/magick+0x419138)
Affected version:
7.0.3.2

Fixed version:
7.0.3.3

Commit fix:
https://github.com/ImageMagick/ImageMagick/commit/aea6c6507f55632829e6432f8177a084a57c9fcc

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

CVE:
CVE-2016-8862

Timeline:
2016-09-14: bug discovered
2016-09-14: bug reported to upstream
2016-10-07: upstream released a patch
2016-10-08: upstream released 7.0.3.3
2016-10-17: blog post about the issue
2016-10-20: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

imagemagick: memory allocation failure in AcquireMagickMemory (memory.c)

Top

Hackers Hit U.S. Senate GOP Committee

Postby BrianKrebs via Krebs on Security »

The national news media has been consumed of late with reports of Russian hackers breaking into networks of the Democratic National Committee. Lest the Republicans feel left out of all the excitement, a report this past week out of The Netherlands suggests Russian hackers have for the past six months been siphoning credit card data from visitors to the Web storefront of the National Republican Senatorial Committee (NRSC).

That’s right: If you purchased a “Never Hillary” poster or donated funds to the NRSC through its Web site between March 2016 and the first week of this month, there’s an excellent chance that your payment card data was siphoned by malware and is now for sale in the cybercrime underground.

News of the break-in comes from Dutch researcher Willem De Groot, co-founder and head of security at Dutch e-commerce site byte.nl. De Groot said the NRSC was one of more than 5,900 e-commerce sites apparently hacked by the same actors, and that the purloined card data was sent to a network of servers operated by a Russian-language Internet service provider incorporated in Belize.

De Groot said he dissected the malware planted on the NRSC’s site and other servers (his analysis of the malware is available here) and found that the hackers used security vulnerabilities or weak passwords to break in to the various e-commerce sites.

The researcher found the malware called home to specific Web destinations made to look like legitimate sites associated with e-commerce activity, such as jquery-cloud[dot]net, visa-cdn[dot]com, and magento-connection[dot]com.

“[The attackers] really went out of their way to pick domain names that look legitimate,” De Groot said.

The NRSC did not respond to multiple requests for comment, but a cached copy of the site’s source code from October 5, 2016 indicates the malicious code was on the site at the time (load this link, click “view source” and then Ctrl-F for “jquery-cloud.net”).

A majority of the malicious domains inserted into the hacked sites by the malware map back to a few hundred Internet addresses assigned to a company called dataflow[dot]su.

Dataflow markets itself as an “offshore” hosting provider with presences in Belize and The Seychelles. Dataflow has long been advertised on Russian-language cybercrime forums as an offshore haven that offers so-called “bulletproof hosting,” a phrase used to describe hosting firms that court all manner of sites that most legitimate hosting firms shun, including those that knowingly host spam and phishing sites as well as malicious software.

De Groot published a list of the sites currently present at Dataflow. The list speaks for itself as a collection of badness, including quite a number of Russian-language sites selling synthetic drugs and stolen credit card data.

According to De Groot, other sites that were retrofitted with the malware included e-commerce sites for the shoe maker Converse as well as the automaker Audi, although he says those sites and the NRSC’s have been scrubbed of the malicious software since his report was published.

But De Groot said the hackers behind this scheme are continuing to find new sites to compromise.

“Last Monday my scans found about 5,900 hacked sites,” he said. “When I did another scan two days later, I found about 340 of those had been fixed, but that another 170 were newly compromised.”

According to the researcher’s analysis, many of the hacked sites are running outdated e-commerce software or content management software. In other cases, it appears the attackers simply brute-forced or guessed passwords needed to administer the sites.

Further, he said, the attackers appear to have inserted their malware into the e-commerce sites’ databases, rather than into the portion of the Web server used to store HTML and other components that make up how the site looks to visitors

“That’s why I think this has remained under the radar for a while now,” De Groot said. “Because some companies use filesystem checkers so that if some file changes on the system they will get a notice that alerts them something is wrong.”

Unfortunately, those same checking systems generally aren’t configured to look for changes in the site’s database files, he explained, since those are expected to change constantly — such as when a new customer order for merchandise is added.

De Groot said he was amazed at how many e-commerce merchants he approached about the hack dismissed the intrusion, reasoning that they employed secure sockets layer (SSL) technology that encrypted the customers’ information end-to-end.

What many Webmaster fail to realize is that just as PC-based trojan horse programs can steal data from Web browsers of infected victims, Web-based keylogging programs can do the same, except they’re designed to steal data from Web server applications.

PC Trojans siphon information using two major techniques: snarfing passwords stored in the browser, and conducting “form grabbing” — capturing any data entered into a form field in the browser before it can be encrypted in the Web session and sent to whatever site the victim is visiting.

Web-based keyloggers also can do form grabbing, ripping out form data submitted by visitors — including names, addresses, phone numbers, credit card numbers and card verification code — as customers are submitting the data during the online checkout process.

These attacks drive home one immutable point about malware’s role in subverting secure connections: Whether resident on a Web server or on an end-user computer, if either endpoint is compromised, it’s ‘game over’ for the security of that Web session.

With PC banking trojans, it’s all about surveillance on the client side pre-encryption, whereas what the bad guys are doing with these Web site attacks involves sucking down customer data post- or pre-encryption (depending on whether the data was incoming or outgoing).
Top

LVM: convert linear to striped

Postby Robbat2 via Move along, nothing to read »

This requires temporarily having 2x the size of your LVM volume. You need to create a mirror of your data, with the new leg of the mirror striped over the target disks, then drop the old leg of the mirror that was not striped. If you want to stripe over ALL of your disks (including the one that was already used), you also need to specify --alloc anywhere otherwise the mirror code will refuse to use any disk twice.
# convert to a mirror (-m1), with new leg striped over 4 disks: /dev/sdb, /dev/sdc, /dev/sdd, /dev/sde
# --mirrorlog core - use in-memory status during the conversion
# --interval 1: print status every second
lvconvert --interval 1 -m1 $myvg/$mylv --mirrorlog core --type mirror --stripes 4 /dev/sd{b,c,d,e}
# drop the old leg, /dev/sda
lvconvert --interval 1 -m0 $myvg/$mylv  /dev/sda
Top

Self-Checkout Skimmers Go Bluetooth

Postby BrianKrebs via Krebs on Security »

This blog has featured several stories about payment card skimming devices designed to be placed over top of credit card terminals in self-checkout lanes at grocery stores and other retailers. Many readers have asked for more details about the electronics that power these so-called “overlay” skimmers. Here’s a look at one overlay skimmer  equipped with Bluetooth technology that allows thieves to snarf swiped card data and PINs wirelessly using nothing more than a mobile phone.

The rather crude video below shows a Bluetooth enabled overlay skimmer crafted to be slipped directly over top of Ingenico iSC250 credit card terminals. These Ingenico terminals are widely used at countless U.S. based merchants; earlier this year I wrote about Ingenico overlay skimmers being found in self-checkout lanes at some WalMart locations.

The demo video briefly shows the electronics hidden on the back side of the overlay skimmer, but most of the sales video demonstrates the Bluetooth functionality built into the device. The video appears to show the skimmer seller connecting his mobile phone to the Bluetooth elements embedded in the skimmer. The demo continues on to show the phone intercepting PIN pad presses and card swipe data.

Your basic Bluetooth signal has a range of approximately 100 meters (328 feet), so theoretically skimmer scammers who placed one of these devices over top of a card terminal in a store’s self-checkout lane could simply sit in a vehicle parked outside the storefront and suck down card data wirelessly in real-time. However, that kind of continuous communication likely would place undue strain on the skimmer’s internal battery, thus dramatically decreasing the length of time the skimmer could collect card and PIN data before needed a new battery.

Rather, such a skimmer would most likely be configured to store the stolen PIN and card data until such time as its owner skulks within range of the device and instructs it to transmit the stored card data.

Concerned about whether the Ingenico terminals at your favorite store may be compromised by one of these overlay skimmers? Turns out, payment terminals retrofitted with overlay skimmers have quite a few giveaways if you know what to look for. Learn how to identify one, by checking out my tutorial, How to Spot Ingenico Self-Checkout Skimmers.

If you liked this piece, have a look at the other skimmer stories in my series, All About Skimmers. And if you’re curious about how card data stolen through skimmers like these are typically sold, take a peek inside a professional carding shop.

The red calipers in the image above show the size differences in various noticeable areas of the case overlay on the left compared to the actual ISC250 on the right. Source: Ingenico.
Thanks to Alex Holden of Hold Security LLC for sharing the above video footage.
Top

IoT Devices as Proxies for Cybercrime

Postby BrianKrebs via Krebs on Security »

Multiple stories published here over the past few weeks have examined the disruptive power of hacked “Internet of Things” (IoT) devices such as routers, IP cameras and digital video recorders. This post looks at how crooks are using hacked IoT devices as proxies to hide their true location online as they engage in a variety of other types of cybercriminal activity — from frequenting underground forums to credit card and tax refund fraud.

Recently, I heard from a cybersecurity researcher who’d created a virtual “honeypot” environment designed to simulate hackable IoT devices. The source, who asked to remain anonymous, said his honeypot soon began seeing traffic destined for Asus and Linksys routers running default credentials. When he examined what that traffic was designed to do, he found his honeypot systems were being told to download a piece of malware from a destination on the Web.

My source grabbed a copy of the malware, analyzed it, and discovered it had two basic functions: To announce to a set of Internet addresses hard-coded in the malware a registration “I’m here” beacon; and to listen for incoming commands, such as scanning for new vulnerable hosts or running additional malware. He then wrote a script to simulate the hourly “I’m here” beacons, interpret any “download” commands, and then execute the download and “run” commands.

The researcher found that the malware being pushed to his honeypot system was designed to turn his faux infected router into a “SOCKS proxy server,” essentially a host designed to route traffic between a client and a server. Most often, SOCKS proxies are used to anonymize communications because they can help obfuscate the true origin of the client that is using the SOCKS server.



When he realized how his system was being used, my source fired up several more virtual honeypots, and repeated the process. Employing a custom tool that allows the user to intercept (a.k.a. “man-in-the-middle”) encrypted SSL traffic, the researcher was able to collect the underlying encrypted data passing through his SOCKS servers and decrypt it.

What he observed was that all of the systems were being used for a variety of badness, from proxying Web traffic destined for cybercrime forums to testing stolen credit cards at merchant Web sites. Further study of the malware files and the traffic beacons emanating from the honeypot systems indicated his honeypots were being marketed on a Web-based criminal service that sells access to SOCKS proxies in exchange for Bitcoin.

Unfortunately, this type of criminal proxying is hardly new. Crooks have been using hacked PCs to proxy their traffic for eons. KrebsOnSecurity has featured numerous stories about cybercrime services that sell access to hacked computers as a means of helping thieves anonymize their nefarious activities online.

And while the activity that my source witnessed with his honeypot project targeted ill-secured Internet routers, there is no reason the same type of proxying could not be done via other default-insecure IoT devices, such as Internet-based security cameras and digital video recorders.

Indeed, my guess is that this is exactly how these other types of hacked IoT devices are being used right now (in addition to being forced to participate in launching huge denial-of-service attacks against targets that criminals wish to knock offline).

“In a way, this feels like 1995-2000 with computers,” my source told me. “Devices were getting online, antivirus wasn’t as prevalent, and people didn’t know an average person’s computer could be enslaved to do something else. The difference now is, the number of vendors and devices has proliferated, and there is an underground ecosystem with the expertise to fuzz, exploit, write the custom software. Plus, what one person does can be easily shared to a small group or to the whole world.”

ROUTER SECURITY 101

As I wrote last week on the lingering and coming IoT security mess, a great many IoT devices are equipped with little or no security protections. On a large number of Internet-connected DVRs and IP cameras, changing the default passwords on the device’s Web-based administration panel does little to actually change the credentials hard-coded into the devices.

Routers, on the other hand, generally have a bit more security built in, but users still need to take several steps to harden these devices out-of-the-box.

For starters, make sure to change the default credentials on the router. This is the username and password pair that was factory installed by the router maker. The administrative page of most commercial routers can be accessed by typing 192.168.1.1, or 192.168.0.1 into a Web browser address bar. If neither of those work, try looking up the documentation at the router maker’s site, or checking to see if the address is listed here. If you still can’t find it, open the command prompt (Start > Run/or Search for “cmd”) and then enter ipconfig. The address you need should be next to Default Gateway under your Local Area Connection.

If you don’t know your router’s default username and password, you can look it up here. Leaving these as-is out-of-the-box is a very bad idea. Most modern routers will let you change both the default user name and password, so do both if you can. But it’s most important to pick a strong password.

When you’ve changed the default password, you’ll want to encrypt your connection if you’re using a wireless router (one that broadcasts your modem’s Internet connection so that it can be accessed via wireless devices, like tablets and smart phones). Onguardonline.gov has published some video how-tos on enabling wireless encryption on your router. WPA2 is the strongest encryption technology available in most modern routers, followed by WPA and WEP (the latter is fairly trivial to crack with open source tools, so don’t use it unless it’s your only option).

But even users who have a strong router password and have protected their wireless Internet connection with a strong WPA2 passphrase may have the security of their routers undermined by security flaws built into these routers. At issue is a technology called “Wi-Fi Protected Setup” (WPS) that ships with many routers marketed to consumers and small businesses. According to the Wi-Fi Alliance, an industry group, WPS is “designed to ease the task of setting up and configuring security on wireless local area networks. WPS enables typical users who possess little understanding of traditional Wi-Fi configuration and security settings to automatically configure new wireless networks, add new devices and enable security.”

However, WPS also may expose routers to easy compromise. Read more about this vulnerability here. If your router is among those listed as vulnerable, see if you can disable WPS from the router’s administration page. If you’re not sure whether it can be, or if you’d like to see whether your router maker has shipped an update to fix the WPS problem on their hardware, check this spreadsheet.

Finally, the hardware inside consumer routers is controlled by software known as “firmware,” and occasionally the companies that make these products ship updates for their firmware to correct security and stability issues. When you’re logged in to the administrative panel, if your router prompts you to update the firmware, it’s a good idea to take care of that at some point. If and when you decide to take this step, please be sure to follow the manufacturer’s instructions to the letter: Failing to do so could leave you with an oversized and expensive paperweight.

Personally, I never run the stock firmware that ships with these devices. Over the years, I’ve replaced the firmware in various routers I purchased with an open source alternative, such as DD-WRT (my favorite) or Tomato. These flavors generally are more secure and offer a much broader array of options and configurations. Again, though, before you embark on swapping out your router’s stock firmware with an open source alternative, take the time to research whether your router model is compatible, and that you understand and carefully observe all of the instructions involved in updating the firmware.

Since October is officially National Cybersecurity Awareness Month, it probably makes sense to note that the above tips on router security come directly from a piece I wrote a while back called Tools for a Safer PC, which includes a number of other suggestions to help beef up your personal and network security.

Top

GnuPG: private key suddenly missing?

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

After updating my workstation, I noticed that keychain reported that it could not load one of the GnuPG keys I passed it on.

 * keychain 2.8.1 ~ http://www.funtoo.org
 * Found existing ssh-agent: 2167
 * Found existing gpg-agent: 2194
 * Warning: can't find 0xB7BD4B0DE76AC6A4; skipping
 * Known ssh key: /home/swift/.ssh/id_dsa
 * Known ssh key: /home/swift/.ssh/id_ed25519
 * Known gpg key: 0x22899E947878B0CE
I did not modify my key store at all, so what happened?

GnuPG upgrade to 2.1

The update I did also upgraded GnuPG to the 2.1 series. This version has quite a few updates, one of which is a change towards a new private key storage approach. I thought that it might have done a wrong conversion, or that the key which was used was of a particular method or strength that suddenly wasn't supported anymore (PGP-2 is mentioned in the article).

But the key is a relatively standard RSA4096 one. Yet still, when I listed my private keys, I did not see this key. I even tried to re-import the secring.gpg file, but it only found private keys that it already saw previously.

I'm blind - the key never disappeared

Luckily, when I tried to sign something with the key, gpg-agent still asked me for the passphraze that I had used for a while on that key. So it isn't gone. What happened?

Well, the key id is not my private key id, but the key id of one of the subkeys. Previously, gpg-agent sought and found the private key associated with the subkey, but now it no longer does. I don't know if this is a bug in the past that I accidentally used, or if this is a bug in the new version. I might investigate that a bit more, but right now I'm happy that I found it.

All I had to do was use the right key id in keychain, and things worked again.

Good, now I can continue debugging networking issues with an azure-hosted system...
Top

This week in vc4 (2016-10-11): QPU user shaders, Processing performance

Postby Eric Anholt via anholt's lj »

Last week I started work on making hello_fft work with the vc4 driver loaded.

hello_fft is a demo program for doing FFTs using the QPUs (the shader core in vc4).  Instead of drawing primitives into a framebuffer like a GL pipeline does, though, it uses the User QPU pipeline, which just hands a uniform stream to a QPU shader instance.

Originally I didn't build a QPU user shader ioctl for vc4 because there's no good way to use this pipeline of the VC4.  The hardware isn't quite capable enough to be exposed as OpenCL or GL compute shaders (some research had been done into this, and the designers' conclusion was that the memory acccess support wasn't quite good enough to be useful).  That leaves you with writing VC4 shaders in raw assembly, which I don't recommend.

The other problem for vc4 exposing user shaders is that, since the GPU sits directly on main memory with no MMU in between, GPU shader programs could access anywhere in system memory.  For 3D, there's no need (in GL 2.1) to do general write back to system memory, so the kernel reads your shader code and rejects shaders if they try to do it.  It also makes sure that you bounds-check all reads through the uniforms or texture sampler.  For QPU user shaders, though, the expected mode of using them is to have the VPM DMA units do general loads and stores, so we'd need new validation support.

If it was just this one demo, we might be willing to lose support for it in the transition to the open driver.  However, some modes of accelerated video decode also use QPU shaders at some stage, so we have to have some sort of solution.

My plan is basically to not do validation and have root-only execution of QPU shaders for now.  The firmware communication driver captures hello_fft's request to have the firmware pass QPU shaders to the V3D hardware, and it redirects it into VC4.  VC4 then maintains the little queue of requests coming in, powers up the hardware, feeds them in, and collects the interrupts from the QPU shaders for when they're done (each job request is required to "mov interrupt, 1" at the end of its last shader to be run).

Dom is now off experimenting in what it will take to redirect video decode's QPU usage onto this code.

The other little project last week was fixing Processing's performance on vc4.  It's one of the few apps that is ported to the closed driver, so it's a likely thing to be compared on.

Unfortunately, Processing was clearing its framebuffers really inefficiently.  For non-tiled hardware it was mostly OK, with just a double-clear of the depth buffer, but for vc4 its repeated glClear()s (rather than a single glClear with all the buffers to be cleared set) were triggering flushes and reloads of the scene, and in one case a render of a full screen quad (and a full screen load before doing so) rather than fast clearing.

The solution was to improve the tracking of what buffers are cleared and whether any primitives have been drawn yet, so that I can coalesce sets of repeated or partial clears together while only updating the colors to be cleared.  There's always a tension in this sort of optimization: Should the GL driver be clever to work around apps behaving badly, or should it push that off to the app developer (more like Vulkan does).  In this case, tiled renderer behavior is sufficiently different from non-tiled renderers, and enough apps will hit this path, that it's well worth it.  For Processing, I saw an improvement of about 10% on the demo I was looking at.

Sadly, Processing won't be a good comparison for open vs closed drivers even after these fixes.  For the closed driver Processing uses EGL, which says that depth buffers become undefined on eglSwapBuffers. In its default mode, though, processing uses GLX, which says that the depth buffer is retained on glXSwapBuffers().  To avoid this extra overhead in its GLX mode, you'd need to use glDiscardFramebufferEXT() right before the swap.  Unfortunately, this isn't connected in gallium yet but shouldn't be hard to do once we have an app that we can test.
Top

Microsoft: No More Pick-and-Choose Patching

Postby BrianKrebs via Krebs on Security »

Adobe and Microsoft today each issued updates to fix critical security flaws in their products. Adobe’s got fixes for Acrobat and Flash Player ready. Microsoft’s patch bundle for October includes fixes for at least five separate “zero-day” vulnerabilities — dangerous flaws that attackers were already exploiting prior to today’s patch release. Also notable this month is that Microsoft is changing how it deploys security updates, removing the ability for Windows users to pick and choose which individual patches to install.

Zero-day vulnerabilities describe flaws that even the makers of the targeted software don’t know about before they start seeing the flaws exploited in the wild, meaning the vendor has “zero days” to fix the bugs.

According to security vendor Qualys, Patch Tuesday updates fix zero-day bugs in Internet Explorer and Edge — the default browsers on different versions of Windows. MS16-121 addresses a zero-day in Microsoft Office. Another zero-day flaw affects GDI+ — a graphics component built into Windows that can be exploitable through the browser. The final zero-day is present in the Internet Messaging component of Windows.

Starting this 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. For example, I’ve often advised home users to hold off on installing .NET updates until all other patches for the month are applied — reasoning that .NET updates are very large and in my experience have frequently been found to be the source of problems when applying huge numbers of patches simultaneously.

But that cafeteria-style patching goes out the…err…Windows with this month’s release. Microsoft made the announcement in May of this year and revisited the subject again in August to add more detail behind its decision:

“Historically, we have released individual patches for these platforms, which allowed you to be selective with the updates you deployed,” wrote Nathan Mercer, a senior product marketing manager at Microsoft. “This resulted in fragmentation where different PCs could have a different set of updates installed leading to multiple potential problems:

  • Various combinations caused sync and dependency errors and lower update quality
  • Testing complexity increased for enterprises
  • Scan times increased
  • Finding and applying the right patches became challenging
  • Customers encountered issues where a patch was already released, but because it was in limited distribution it was hard to find and apply proactively
By moving to a rollup model, we bring a more consistent and simplified servicing experience to Windows 7 SP1 and 8.1, so that all supported versions of Windows follow a similar update servicing model. The new rollup model gives you fewer updates to manage, greater predictability, and higher quality updates. The outcome increases Windows operating system reliability, by eliminating update fragmentation and providing more proactive patches for known issues. Getting and staying current will also be easier with only one rollup update required. Rollups enable you to bring your systems up to date with fewer updates, and will minimize administrative overhead to install a large number of updates.”

Microsoft’s patch policy changes are slightly different for home versus business customers. 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). I have no doubt this simplifies things for Microsoft and likely saves them a ton of money, but my concern is this will leave end-users unable to apply critical patches simply due to a single patch breaking something.

It’s important to note that several update types won’t be included in a rollup, including those for Adobe Flash Player. As it happens, Adobe today issued an update for its Flash Player browser plugin that fixes a dozen security vulnerabilities in the program. The company said it is currently not aware of any attempts to exploit these flaws in the wild (i.e., no zero-days in this month’s Flash patch).

The latest update brings Flash to v. 23.0.0.185 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. I’ve got more on that approach (as well as slightly less radical solutions ) in A Month Without Adobe Flash Player.

If you choose to update, please do it today. The most recent versions of Flash should be available from this Flash distribution page or 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).

Finally, Adobe released security updates that correct a whopping 71 flaws in its PDF Reader and Acrobat products. If you use either of these software packages, please take a moment to update them.
Top

FreeBSD 11.0-RELEASE Available

Postby Webmaster Team via FreeBSD News Flash »

FreeBSD 11.0-RELEASE is now available. Please be sure to check the Release Notes and Release Errata before installation for any late-breaking news and/or issues with 11.0. More information about FreeBSD releases can be found on the Release Information page.
Top

Greg Truskey, TruCo

Postby Dan Langille via Dan Langille's Other Diary »

I’m writing this to document the facts. I’ll leave adjectives and opinions to you. Greg Truskey, TruCo was hired to perform renovations which started in August 2015. The estimate was 11 weeks. He was on site from about 9am to 3:30pm. Arriving earlier or late was uncommon. On days he would not arrive, we would [...]
Top

This week in vc4 (2016-10-03): HDMI, X testing and cleanups, VCHIQ

Postby Eric Anholt via anholt's lj »

Last week Adam Jackson landed my X testing series, so now at least 3 of us pushing code are testing glamor with every commit.  I used the series to test a cleanup of the Render extension related code in glamor, deleting 550 lines of junk.  I did this while starting to work on using GL sampler objects, which should help reduce our pixmap allocation and per-draw Render overhead.   That patch is failing make check so far.

The big project for the week was tackling some of the HDMI bug reports.  I pulled out my bigger monitor that actually takes HDMI input, and started working toward getting it to display all of its modes correctly.  We had an easy bug in the clock driver that broke changing to low resolutions: trying to drive the PLL too slow, instead of driving the PLL in spec and using the divider to get down to the clock we want.  We needed infoframes support to fix purple borders on the screen.  We were doing our interlaced video mode programming pretty much entirely wrong (it's not perfect yet, but 1 of the 3 interlaced modes on my montior displays correctly and they all display something).  Finally, I added support for double-clocked CEA modes (generally the low resolution, low refresh ones in your list.  These are probably particularly interesitng for RPi due to all the people running emulators).

Finally, one of the more exciting things for me was that I got general agreement from gregkh to merge the VCHIQ driver through the staging tree, and he even put the initial patch together for me.  If we add in a couple more small helper drivers, we should be able to merge the V4L2 camera driver, and hopefully get closer to doing a V4L2 video decode driver for upstream.  I've now tested a messy series that at least executes "vcdbg log msg."  Those other drivers will definitely need some cleanups, though.
Top

pkg upgrade: Certificate verification failed for /C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Class 2 IV Server CA

Postby Dan Langille via Dan Langille's Other Diary »

I noticed this on one FreeBSD server today: $ pkg -vv | grep url url: "pkg+http://services.unixathome.org/packages/103amd64-default-master-list/", I decided: let’s use https, not http, there. After making the change (in my case, it was in /usr/local/etc/pkg/repos/local.conf, I tried upgraded packages, and it barfed: $ sudo pkg upgrade Updating local repository catalogue... Certificate verification failed for /C=IL/O=StartCom [...]
Top

FreeBSD 11.0-RELEASE Status Update

Postby Webmaster Team via FreeBSD News Flash »

The final 11.0-RELEASE is going to be rebuilt in order to address a few last-minute items that were discovered after the release tag. Please see the official announcement from the Release Engineering team for more information.
Top

We do not ship SELinux sandbox

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

A few days ago a vulnerability was reported in the SELinux sandbox user space utility. The utility is part of the policycoreutils package. Luckily, Gentoo's sys-apps/policycoreutils package is not vulnerable - and not because we were clairvoyant about this issue, but because we don't ship this utility.

What is the SELinux sandbox?

The SELinux sandbox utility, aptly named sandbox, is a simple C application which executes its arguments, but only after ensuring that the task it launches is going to run in the sandbox_t domain.

This domain is specifically crafted to allow applications most standard privileges needed for interacting with the user (so that the user can of course still use the application) but removes many permissions that might be abused to either obtain information from the system, or use to try and exploit vulnerabilities to gain more privileges. It also hides a number of resources on the system through namespaces.

It was developed in 2009 for Fedora and Red Hat. Given the necessary SELinux policy support though, it was usable on other distributions as well, and thus became part of the SELinux user space itself.

What is the vulnerability about?

The SELinux sandbox utility used an execution approach that did not shield off the users' terminal access sufficiently. In the POC post we notice that characters could be sent to the terminal through the ioctl() function (which executes the ioctl system call used for input/output operations against devices) which are eventually executed when the application finishes.

That's bad of course. Hence the CVE-2016-7545 registration, and of course also a possible fix has been committed upstream.

Why isn't Gentoo vulnerable / shipping with SELinux sandbox?

There's some history involved why Gentoo does not ship the SELinux sandbox (anymore).

First of all, Gentoo already has a command that is called sandbox, installed through the sys-apps/sandbox application. So back in the days that we still shipped with the SELinux sandbox, we continuously had to patch policycoreutils to use a different name for the sandbox application (we used sesandbox then).

But then we had a couple of security issues with the SELinux sandbox application. In 2011, CVE-2011-1011 came up in which the seunshare_mount function had a security issue. And in 2014, CVE-2014-3215 came up with - again - a security issue with seunshare.

At that point, I had enough of this sandbox utility. First of all, it never quite worked enough on Gentoo as it is (as it also requires a policy which is not part of the upstream release) and given its wide open access approach (it was meant to contain various types of workloads, so security concessions had to be made), I decided to no longer support the SELinux sandbox in Gentoo.

None of the Gentoo SELinux users ever approached me with the question to add it back.

And that is why Gentoo is not vulnerable to this specific issue.
Top

Changing the default host for Cisco AnyConnect OSX client

Postby Dan Langille via Dan Langille's Other Diary »

My first day back from EuroBSDCon 2016, I wanted to fix an issue which arose before the conference. My Cisco AnyConnect client configuration contained old hosts which I no longer used, but didn’t contain the host I was primarily using now. I could add the host, but upon restart, that new host was no longer [...]
Top

Fn Backlight auf XC1506 zum laufen bringen

Postby bed via Zockertown: Nerten News »

Eigentlich lief ja alles zur vollsten Zufriedenheit auf meinem Tuxedo Laptop... Doch was macht der Esel, wenn's ihm zu gut geht? Richtig, er geht auf's Eis.

Will sagen, so richtig glücklich bin ich mit Ubuntu nicht. Keine Frage, die Unterstützung von proprietäre Hardware (NVidia) ist spitze, aber ich mag Unity nicht, hatte Gnome3 Shell installiert und es ging bis auf die Fn Backlightsteuerung im Gnome alles einwandfrei. Das habe ich mit einem xbindkeys auf andere Tasten gelegt, damit wäre eigentlich alles geregelt.

Doch mich stört dieser sudo Mist, klar, auch das hätte ich abschalten können, aber ich wollte aufs Eis und wieder zurück zur Mutter.

Also habe ich Debian Stretch (noch im Testing) installiert, was gar nicht so einfach war, weil ich die Volumegroups behalten wollte. Schließlich habe ich es hinbekommen und bis auf die Helligkeitsverstellung des Backlights ging alles out of the Box. Ich habe noch das Modul von Tuxedo installiert, tuxedo-wmi.

Interessanterweise war die Desktop Notification bereits funktionsfähig, nur das Backlight scherte sich nicht und blieb auf einer Stufe stehen. Der Wert der Helligkeitsstufe wurde allerdings hier

/sys/class/backlight/acpi_video0/actual_brightness
geschrieben. Das war ein guter Beginn.

Um es kurz zu machen, die Lösung ist jetzt inotify-tools installieren und dann:

Eintrag in /etc/default/grub für Tuxedo XC1506

# Eintrag in /etc/default/grub
# Wichtig ist, dass man nicht! acpi_backlight=vendor setzt!
    $ grep ^GRUB_CMDLINE_LINUX_DEFAULT= /etc/default/grub
    GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_os_name=Linux acpi_osi= acpi_backlight=video vga=791"

Dieses Script überwacht mit inotify die Änderungen in actual_brightness

Das Script ist eine Modification von hier

# Dieses Script überwacht mit inotify die Änderungen in actual_brightness
$ cat /usr/local/bin/xbacklightmon
#!/bin/bash

    path=/sys/class/backlight/acpi_video0

    read -r max < "$path"/max_brightness

    luminance() {
        read -r level < "$path"/actual_brightness
        factor=10
        printf '%d\n' "$(( $level * $factor))"
    }


    xbacklight -set "$(luminance)"

    inotifywait -me modify --format '' "$path"/actual_brightness | while read; do
        xbacklight -set "$(luminance)"
    done

Der Autostart Eintrag

# Der Autostart Eintrag
$ cat .config/autostart/xbacklightmon.desktop
    [Desktop Entry]
    Type=Application
    Exec=/usr/local/bin/xbacklightmon
    Hidden=false
    X-GNOME-Autostart-enabled=true
    Name[de_de]=xbacklightmon
    Name=xbacklightmon
    Comment[de_de]=Workaround fürs backlight



Top

This week in vc4 (2016-09-26): XDC 2016, glamor testing, glamor performance

Postby Eric Anholt via anholt's lj »

Last week I spent at XDS 2016 with other graphics stack developers.

I gave a talk on X Server testing and our development model.  Since playing around in the Servo project (and a few other github-centric communities) recently, I've become increasingly convinced that github + CI + automatic merges is the right way to go about software development now.  I got a warmer reception from the other X Server developers than I expected, and I hope to keep working on building out this infrastructure.

I also spent a while with keithp and ajax (other core X developers) talking about how to fix our rendering performance.  We've got two big things hurting vc4 right now: Excessive flushing, and lack of bounds on rendering operations.

The excessive flushing one is pretty easy.  X currently does some of its drawing directly to the front buffer (I think this is bad and we should stop, but that *is* what we're doing today).  With glamor, we do our rendering with GL, so the driver accumulates a command stream over time.  In order for the drawing to the front buffer to show up on time, both for running animations, and for that last character you typed before rendering went idle, we have to periodically flush GL's command stream so that its rendering to the front buffer (if any) shows up.

Right now we just glFlush() every time we might block sending things back to a client, which is really frequent.  For a tiling architecture like vc4, each glFlush() is quite possibly a load and store of the entire screen (8MB).

The solution I started back in August is to rate-limit how often we flush.  When the server wakes up (possibly to render), I arm a timer.  When it fires, I flush and disarm it until the next wakeup.  I set the timer to 5ms as an arbitrary value that was clearly not pretending to be vsync.  The state machine was a little tricky and had a bug it seemed (or at least a bad interaction with x11perf -- it was unclear).  But ajax pointed out that I could easily do better: we have a function in glamor that gets called right before it does any GL operation, meaning that we could use that to arm the timer and not do the arming every time the server wakes up to process input.

Bounding our rendering operations is a bit trickier.  We started doing some of this with keithp's glamor rework: We glScissor() all of our rendering to the pCompositeClip (which is usually the bounds of the current window).  For front buffer rendering in X, this is a big win on vc4 because it means that when you update an uncomposited window I know that you're only loading and storing the area covered by the window, not the entire screen.  That's a big bandwidth savings.

However, the pCompositeClip isn't enough.  As I'm typing we should be bounding the GL rendering around each character (or span of them), so that I only load and store one or two tiles rather than the entire window.  It turns out, though, that you've probably already computed the bounds of the operation in the Damage extension, because you have a compositor running!  Wouldn't it be nice if we could just reuse that old damage computation and reference it?

Keith has started on making this possible: First with the idea of const-ifying all the op arguments so that we could reuse their pointers as a cheap cache key, and now with the idea of just passing along a possibly-initialized rectangle with the bounds of the operation.  If you do compute the bounds, then you pass it down to anything you end up calling.

Between these two, we should get much improved performance on general desktop apps on Raspberry Pi.

Other updates: Landed opt_peephole_sel improvement for glmark2 performance (and probably mupen64plus), added regression testing of glamor to the X Server, fixed a couple of glamor rendering bugs.
Top