Accusoft's Blog

Are there security advantages to an alternate viewer, for example Prizm Content Connect or Prizm Cloud Connect?

Security is on everyone’s mind these days, and if it isn’t it should be.  It is certainly on Oracle’s mind as they have had a lot of Java vulnerabilities reported in the last few months. Microsoft also released their largest ever Patch Tuesday to address 57 different vulnerabilities in some of their top products.  Both of these companies are top tier vendors and have millions of installed applications.  Having that kind of install base makes them prime targets.  A reasonable question then might be “Are there security advantages if I went with someone else?”  I’ll explore this question in relation to PDF and document viewers.

The first thing to realize about a “PDF vulnerability” or a “Word vulnerability” is that this is actually shorthand for “A vulnerability in application X when acting on files of type Y” where Y happens to be a PDF or Word document.  An in-the-wild exploit that uses a PDF vulnerability must target a specific application, usually Adobe Acrobat Reader, and usually it targets a specific version.  This means that if you are viewing a malicious PDF targeted at Adobe Acrobat Reader with Prizm Content Connect, or Prizm Cloud Connect then this file will most likely fail to render instead of running malicious code.  This is not a new idea, this is Security through Minority.  This is the idea that an attacker has limited time and is trying to extract maximum value out of that time and so they will target the most widespread applications.  While this might be true in the general case, it might not be true in the targeted case.  The number one prediction from Kaspersky Lab’s Security Bulletin 2012 is that targeted attacks and cyber-espionage are on the rise, so it’s something to consider.

Read more on limiting security risks with a document viewer.

Back in November two of our engineers went to the Amazon 2012 re: Invent conference and couldn’t stop talking about how good it was.  Once the videos were posted online I started looking them over and found a lot of great material.  Enough so that the entire month of January was devoted to Amazon Web Services.

2012 re: Invent Day 2: Fireside Chat with Jeff Bezos & Werner Vogels   

Jeff Bezos covers how Lean Manufacturing ideas have influenced the workings of Amazon and how he strongly believes in aligning the companies goals with the customers goals.  His comment about Amazon not deserving to make money if you never use the Kindle rings true to me both as a customer and a business professional.  I had never heard the idea of focusing on the aspects of your business that don’t change, such as always wanting books delivered faster, as a way to gain market advantage.  At the end he covers some of his more ambitious projects, the 10,000 year clock and Blue Origin.

AWS re:Invent ARC 205: Building Web-Scale Applicattons With AWS

A great presentation that covered the fundamentals of what you should be considering when building a Web-Scale Application.  Things like Satelessness, separating state from application servers, Idempotency, and database partitioning.  The explanation of the CAP Theorem was short and sweet.  James Hamilton showed up at the end to do a Top 5 Reasons for Early Postmortem that everyone enjoyed and inspired us to watch the next video.

Read more to see additional videos from AWS re:Invent.

Every Friday since somewhere in 2007 or 2008, developers and other co-workers at Accusoft come together for Tech Talk during lunch and watch a video presentation centered around topics of interest.  These are usually videos from conferences likeTechEd, Google I/O, or any of the other numerous technical events that happen each year.  We also watch inspirational videos from TED or other business, management or general interest videos.  Accusoft is nice enough to supply us lunch during the videos and everyone has a good time sharing in the new information. 

November is the last month that I show Friday videos since December is often filled with people taking various days off. Since it’s hard work finding videos every week, having a month off to build up a stockpile of videos is actually relaxing.

We started the month off with a video from TechEd North America 2012, then a few videos from the Microsoft BUILD 2012 conference that just completed, and finish the month with some thought-provoking TED Talks.

Metrics That Matter: Improving Lean and Agile, Kanban and Scrum
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DEV339 
It discusses some of the general problems with metrics and gives a pretty good introduction to the different things measured in Kanban and Scrum.

SignalR
http://channel9.msdn.com/Events/Build/2012/3-034 
SignalR looks like a great abstraction layer over something that is becoming more and more common, real-time web communication.  I love that they’ve built various fallback implementations, allowing you to seamlessly use WebSockets all the way down to Long Polling with the exact same code.

Read more for videos from BUILD 2012 and TED.

This is the final article in my two part series on my motivation and process for making MEM_TOP_DOWN a per-process flag. Previously, in Part 1, I explained user-mode solutions that I thought fell short. In Part 2, I will cover reverse engineering the OS mechanism behind MEM_TOP_DOWN and how to use it.

Knowing that NtAllocateVirtualMemory is responsible for allocating memory it is reasonable to assume that the code path that handles the MEM_TOP_DOWN flag passed in as a parameter is the same code path that handles the MEM_TOP_DOWN set in the AllocationPreferences in the registry.  

For this exercise I’ll be using examples from the 32-bit kernel as the analysis is easier to follow, for our purposes the 64-bit kernel behaves the same way.

Read more to learn how to use MEM_TOP_Down.

In this two part series I’ll discuss my motivations and process for making MEM_TOP_DOWN a per-process flag.  In Part 1 I’ll explain user-mode solutions that I think fall short and in Part 2 I’ll cover reverse engineering the OS mechanism behind MEM_TOP_DOWN and how to make use of it.

When porting 32-bit code to 64-bit it is common to have pointer truncation bugs.  Pointer truncation arises from the difference in sizes between pointer types, ‘void*’, and the integral types, ‘int’, ‘long’.  On 32-bit architectures all of these types are the same size, on 64-bit Windows ‘void*’ is twice as large as ‘int’ and ‘long’.

These bugs remain undetected because most applications do not use a lot of memory and the virtual addresses allocated are below the 4GB mark that fits into a 32-bit value.  A project compiled with strict warnings can usually find these issues, and if not the compiler then static analysis tools are good at finding them as well.  However, even those tools won’t help you if you’ve written your own ASM optimizations and mistakenly used EAX instead of RAX.

Read more to learn how and why you make MEM_TOP_Down a per-process flag.