Windows hyper v 2018: обновление версии виртуальной машины в Hyper-V на Windows или Windows Server

Описание обновления безопасности для Windows Hyper-V уязвимость отказа в обслуживании в Windows Server 2008: 13 марта 2018 г.

Windows Server 2008 Foundation Windows Server 2008 Enterprise without Hyper-V Windows Server 2008 Service Pack 2 Windows Server 2008 Datacenter Windows Server 2008 for Itanium-Based Systems Windows Server 2008 Datacenter without Hyper-V Windows Server 2008 Enterprise Windows Server 2008 Web Edition Windows Server 2008 Standard Еще…Меньше

Обзор

Существует уязвимость отказа в обслуживании, когда Microsoft Hyper-V сетевого коммутатора на хост-сервере не удается проверить входные данные от привилегированного пользователя на гостевой операционной системы.

Дополнительные сведения о данной уязвимости CVE-2018-0885см.

Дополнительные сведения

Важные Если вы установить языковой пакет после установки этого обновления, необходимо повторно установить это обновление. Таким образом, рекомендуется установить все языковые пакеты, которые вам нужны, прежде чем установить данное обновление. Дополнительные сведения содержатся в разделе Установка языковых пакетов для Windows.

Как получить и установить обновление

Метод 1. Центр обновления Windows

Это обновление доступно через Центр обновления Windows. При включении автоматического обновления, обновления будут загружаться и устанавливаться автоматически. Дополнительные сведения о том, как включить автоматическое обновление см центра обновления Windows: вопросы и ответы по.

Метод 2: Каталог Центра обновления Майкрософт

Для получения отдельного пакета для данного обновления перейдите на веб-сайт каталога Центра обновления Майкрософт.

Сведения о развертывании

Дополнительные сведения о развертывании данного обновления для системы безопасности перейдите к следующей статье Microsoft Knowledge Base:

Сведения о развертывании обновления безопасности: 13 марта 2018 г.

Дополнительные сведения

Сведения о файлах

Английская (США) версия данного обновления программного обеспечения устанавливает файлы, атрибуты которых указаны в приведенных ниже таблицах. Дата и время для этих файлов указаны в формате общего скоординированного времени (UTC). Даты и время для файлов на локальном компьютере отображаются в местном времени с вашей текущей смещения летнего времени (DST). Кроме того при выполнении определенных операций с файлами даты и время могут изменяться.

Примечания

Файлы МАНИФЕСТА (.manifest) и файлы MUM (.mum), которые устанавливаются не указываются.

Получение справки и поддержки данного обновления для системы безопасности

Справка по установке обновлений: обновления Windows: вопросы и ответы по

Решения по безопасности для ИТ-специалистов: Устранение неполадок и поддержка безопасности TechNet

Справка по защите от вирусов и вредоносных программ на компьютере под управлением Windows: Безопасность Майкрософт

Локальная поддержка для вашей страны: Международная поддержка

Сведения о файлах для Windows Server 2008

Сведения о хэше файлов

Для всех поддерживаемых версий на базе x64

Hyper-V

14 января, 2022

Microsoft отозвала обновления для Windows Server из-за серьезных неполадок

После установки патчей контроллеры домена попадают в петлю перезагрузки, ReFS становится недоступной, а Hyper-V перестает загружаться.

30 июля, 2021

Опубликована информация о критической уязвимости в гипервизоре Hyper-V

Проблема может быть проэксплуатирована для удаленного выполнения кода или вызова состояния «отказа в обслуживании».

8 сентября, 2020

Уязвимость в Windows 10 позволяет создавать файлы в системных папках

Проблема затрагивает большинство редакций Windows 10 и ее чрезвычайно легко проэксплуатировать.

8 августа, 2019

Microsoft исправила непризнанную сначала уязвимость в RDP

Компания выпустила патч, когда стало известно, что уязвимость также затрагивает Hyper-V.

6 марта, 2019

Zerodium заплатит до $500 тыс. за 0Day-уязвимости в Hyper-V и vSphere

Предложение будет действовать в течение нескольких месяцев.

9 августа, 2018

Microsoft указала место, где нужно искать уязвимости

Компания рассказала об архитектуре Hyper-V и отметила элементы, требующие пристального внимания «охотников за уязвимостями».

5 марта, 2010

Red Hat Linux теперь можно запускать на Hyper-V

Корпорация Microsoft представила набор драйверов, позволяющих запускать операционную систему Red Hat Linux на виртуализаторе Hyper-V.

11 ноября, 2008

Microsoft проводит первую онлайн-конференцию по виртуализации

В рамках конференции компания Microsoft представляет финальную версию системы управления виртуальной инфраструктурой System Center Virtual Machine Manager 2008. Принять участие в мероприятии уже сейчас может любой желающий, воспользовавшись ссылкой www.hyper-v.ru.

15 сентября, 2008

Microsoft и Novell предложили SUSE Linux на Windows Server с Hyper-V

Новое предложение компаний — серверный дистрибутив SUSE Linux Enterprise Server, настроенный и протестированный в качестве оптимизированной гостевой операционной системы для запуска на Windows Server 2008 Hyper-V

28 июля, 2008

Microsoft выпустит Virtual Machine Manager в сентябре

После выхода Virtual Machine Manager 2008 будет поставляться как автономный продукт. К концу 2008 года он войдет в состав более масштабной и консолидированной системы System Center Server Management Suite Enterprise, которая пока также находится в разработке.

30 июня, 2008

Компания Microsoft объявила о выпуске полнофункциональной версии технологии виртуализации Hyper-V

Hyper-V предлагает заказчикам масштабируемую и высокопроизводительную платформу виртуализации, внедряемую в существующие ИТ-инфраструктуры и позволяющую консолидировать некоторые из наиболее важных рабочих нагрузок.

21 марта, 2008

Финальная версия системы виртуализации Hyper-V выйдет в августе

Корпорация Microsoft объявила о доступности полнофункциональной предрелизной версии продукта Microsoft Hyper-V – долгожданного ПО виртуализации, допускающего запуск нескольких операционных систем на одном сервере.

Подпишитесь на email рассылку

Подпишитесь на получение последних материалов по безопасности от SecurityLab. ru —
новости, статьи, обзоры уязвимостей и мнения аналитиков.

Ежедневный выпуск от SecurityLab.Ru

Еженедельный выпуск от SecurityLab.Ru

Нажимая на кнопку, я принимаю условия соглашения.

Hyper-V HyperClear Mitigation для сбоя терминала L1

• Статья
• 09.05.2023

Введение

Недавно было объявлено о новой уязвимости побочного канала спекулятивного выполнения, которая затрагивает ряд процессоров Intel Core и Intel Xeon. Эта уязвимость, называемая L1 Terminal Fault (L1TF) и присвоенная гипервизорам CVE 2018-3646, может использоваться для целого ряда атак через границы изоляции, включая атаки внутри операционной системы из пользовательского режима в режим ядра, а также межсетевые атаки. -Атаки ВМ. Из-за характера этой уязвимости создание надежного средства защиты между виртуальными машинами, которое не приводит к значительному снижению производительности, является особенно сложной задачей.

Для Hyper-V мы разработали комплексное средство защиты от этой атаки, которое мы называем HyperClear. Это средство защиты используется Microsoft Azure и доступно в Windows Server 2016 и более поздних версиях. Решение HyperClear по-прежнему позволяет безопасно использовать SMT (гиперпоточность) с виртуальными машинами, и, судя по нашим наблюдениям за развертыванием этого решения в Microsoft Azure, HyperClear оказывает относительно незначительное влияние на производительность.

Мы уже поделились информацией о HyperClear с отраслевыми партнерами. Поскольку мы получили вопросы о том, как мы можем смягчить уязвимость L1TF без ущерба для производительности, мы хотели поделиться техническим обзором смягчения HyperClear и того, как оно смягчает атаки по сторонним каналам со спекулятивным выполнением L1TF на виртуальных машинах.

Обзор влияния L1TF на изоляцию ВМ

Как описано здесь, основная предпосылка уязвимости L1TF заключается в том, что она позволяет виртуальной машине, работающей на ядре процессора, отслеживать любые данные в кэше данных L1 на этом ядре.

Обычно гипервизор Hyper-V изолирует, к каким данным может получить доступ виртуальная машина, используя возможности преобразования адресов памяти, предоставляемые процессором. В случае процессоров Intel функция расширенных таблиц страниц (EPT) в Intel VT-x используется для ограничения адресов системной физической памяти, к которым может получить доступ виртуальная машина.

При нормальном выполнении гипервизор использует функцию EPT для ограничения доступа к физической памяти виртуального процессора виртуальной машины во время ее работы. Это также ограничивает доступ виртуального процессора к данным в кэше, поскольку физический процессор обеспечивает доступ виртуального процессора только к данным в кэше, соответствующим физическим адресам системы, доступным через конфигурацию EPT виртуального процессора.

Успешно используя уязвимость L1TF, можно обойти конфигурацию EPT для виртуального процессора во время спекулятивного выполнения, связанного с этой уязвимостью. Это означает, что виртуальный процессор в виртуальной машине может спекулятивно получить доступ ко всему в кэше данных L1, независимо от защиты памяти, настроенной конфигурацией EPT процессора.

Технология Intel Hyper-Threading (HT) представляет собой разновидность одновременной многопоточности (SMT). При использовании SMT ядро ​​имеет несколько потоков SMT (также называемых логическими процессорами), и эти логические процессоры (LP) могут выполняться одновременно на ядре. SMT еще больше усложняет эту уязвимость, так как кеш данных L1 совместно используется родственными потоками SMT одного ядра. Таким образом, виртуальный процессор для виртуальной машины, работающей в потоке SMT, может спекулятивно получить доступ ко всему, что было внесено в кэш данных L1 родственными потоками SMT. Это может сделать небезопасным запуск нескольких контекстов изоляции на одном ядре. Например, если на одном логическом процессоре ядра SMT работает виртуальный процессор VM A, а на другом логическом процессоре ядра работает виртуальный процессор VM B, конфиденциальные данные из VM B могут быть видны VM A (и наоборот). наоборот).

Аналогично, если один логический процессор ядра SMT выполняет виртуальный процессор для виртуальной машины, а другой логический процессор ядра SMT работает в контексте гипервизора, гостевая виртуальная машина может спекулятивно получить доступ к конфиденциальным данным, помещенным в кэш с помощью гипервизор.

Basic Inter-VM Mitigation

Чтобы уменьшить уязвимость L1TF в контексте изоляции между VM, наиболее простое смягчение включает два ключевых компонента:

1. Flush L1 Data Cache On Guest VM Entry — Каждый раз, когда гипервизор переключает поток процессора (логический процессор) для выполнения в контексте гостевого виртуального процессора, гипервизор может сначала очистить кэш данных L1. Это гарантирует, что в кэше не останется конфиденциальных данных от гипервизора или ранее запущенных гостевых виртуальных процессоров. Чтобы гипервизор мог сбрасывать кэш данных L1, Intel выпустила обновленный микрокод, который предоставляет архитектурные средства для очистки кэша данных L1.
2. Отключить SMT — даже при очистке кэша данных L1 при входе в гостевую ВМ все еще существует риск того, что одноуровневый поток SMT может перенести конфиденциальные данные в кэш из другого контекста безопасности. Чтобы смягчить это, можно отключить SMT, что гарантирует выполнение только одного потока на ядре процессора.

Средство устранения рисков L1TF для Hyper-V до Windows Server 2016 использует средство устранения, основанное на этих компонентах. Однако у этого базового средства защиты есть существенный недостаток, заключающийся в том, что SMT необходимо отключить, что может значительно снизить общую производительность системы. Кроме того, это смягчение может привести к очень высокой скорости очистки кэша данных L1, поскольку гипервизор может переключать поток между гостевым контекстом и контекстом гипервизора много тысяч раз в секунду. Эти частые сбросы кэша также могут снизить производительность системы.

HyperClear Inter-VM Mitigation

Чтобы устранить недостатки базового L1TF Inter-VM Mitigation, мы разработали HyperClear mitigation. Смягчение последствий HyperClear опирается на три ключевых компонента для обеспечения надежной изоляции между виртуальными машинами:

1. Core Scheduler
2. Изоляция адресного пространства виртуального процессора
3. Очистка конфиденциальных данных

Core Scheduler

Традиционный планировщик Hyper-V работает на уровне отдельных потоков SMT (логических процессоров). При принятии решений о планировании планировщик Hyper-V назначал виртуальный процессор потоку SMT, независимо от того, что делали родственные потоки SMT того же ядра. Таким образом, на одном физическом ядре могут одновременно работать виртуальные процессоры с разных ВМ.

Начиная с Windows Server 2016, Hyper-V представила новую реализацию планировщика для систем SMT, известную как «основной планировщик». Когда Core Scheduler включен, Hyper-V назначает виртуальные ядра физическим ядрам. Таким образом, когда для виртуальной машины запланировано виртуальное ядро, она получает исключительное использование физического ядра, и виртуальная машина никогда не будет совместно использовать физическое ядро ​​с другой виртуальной машиной.

С помощью Core Scheduler виртуальная машина может безопасно использовать преимущества SMT (Hyper-Threading). Когда виртуальная машина использует SMT, планирование гипервизора позволяет виртуальной машине использовать все потоки SMT ядра одновременно.

Таким образом, Core Scheduler обеспечивает необходимую защиту, заключающуюся в том, что данные виртуальной машины не будут напрямую раскрыты в родственных потоках SMT. Это защищает от раскрытия данных виртуальной машины между потоками, поскольку две разные виртуальные машины никогда не работают одновременно в разных потоках одного и того же ядра.

Однако одного Core Scheduler недостаточно для защиты от всех форм утечки конфиденциальных данных через потоки SMT. По-прежнему существует риск утечки данных гипервизора через одноуровневые потоки SMT.

Изоляция адресного пространства виртуального процессора

Потоки SMT на ядре могут независимо входить и выходить из контекста гипервизора в зависимости от их активности. Например, такие события, как прерывания, могут привести к тому, что поток SMT перестанет выполнять контекст гостевого виртуального процессора и начнет выполнение контекста гипервизора. Это может происходить независимо для каждого потока SMT, поэтому один поток SMT может выполняться в контексте гипервизора, в то время как его родственный поток SMT все еще работает в контексте гостевого виртуального процессора виртуальной машины. Злоумышленник, запускающий код в менее надежном контексте виртуального процессора гостевой ВМ в одном потоке SMT, может затем использовать уязвимость побочного канала L1TF, чтобы потенциально наблюдать конфиденциальные данные из контекста гипервизора, работающего в родственном потоке SMT.

Одним из возможных решений этой проблемы является координация входа и выхода гипервизора между потоками SMT одного и того же ядра. Хотя это эффективно снижает риск раскрытия информации, это может значительно снизить производительность.

Вместо того, чтобы координировать вход и выход гипервизора между потоками SMT, Hyper-V использует строгую изоляцию данных в гипервизоре для защиты от злонамеренной гостевой ВМ, использующей уязвимость L1TF для наблюдения за конфиденциальными данными гипервизора. Гипервизор Hyper-V обеспечивает эту изоляцию за счет поддержки отдельных виртуальных адресных пространств в гипервизоре для каждого гостевого потока SMT (виртуального процессора). Когда контекст гипервизора вводится в конкретный поток SMT, единственными данными, доступными для гипервизора, являются данные, связанные с гостевым виртуальным процессором, связанным с этим потоком SMT. Это обеспечивается с помощью таблицы страниц гипервизора, выборочно отображающей только память, связанную с гостевым виртуальным процессором. Никакие данные для любого другого гостевого виртуального процессора не адресуются, и поэтому гипервизор может перенести в кэш данных L1 только данные, связанные с этим текущим гостевым виртуальным процессором.

Таким образом, независимо от того, работает ли данный виртуальный процессор в контексте виртуального процессора гостевой ВМ или в контексте гипервизора, в кэш могут быть помещены только данные, связанные с активным виртуальным процессором гостевой машины. Никакие дополнительные привилегированные секреты гипервизора или данные от других гостевых виртуальных процессоров не могут быть перенесены в кэш данных L1.

Эта надежная изоляция адресного пространства обеспечивает два явных преимущества:

1. Гипервизору не нужно координировать вход и выход в гипервизор через родственные потоки SMT. Таким образом, потоки SMT могут входить и выходить из контекста гипервизора независимо друг от друга без каких-либо дополнительных потерь производительности.
2. Гипервизору не нужно очищать кэш данных L1 при входе в контекст гостевой виртуальной машины из контекста гипервизора. Поскольку единственные данные, которые могут быть перенесены в кеш при выполнении в контексте гипервизора, — это данные, связанные с гостевым виртуальным процессором, нет риска привилегированного/частного состояния в кеше, которое необходимо защитить от гостя. Таким образом, при такой строгой изоляции адресного пространства гипервизору нужно только очищать кэш данных L1 при переключении между виртуальными ядрами на физическом ядре. Это происходит гораздо реже, чем переключения между контекстами гипервизора и гостевой виртуальной машины.

Очистка конфиденциальных данных

В некоторых случаях изоляция адресного пространства виртуального процессора недостаточна для обеспечения изоляции конфиденциальных данных. В частности, в случае вложенной виртуализации один виртуальный процессор может запускать несколько гостевых виртуальных процессоров. Рассмотрим случай гостевой виртуальной машины L1 с вложенным гипервизором (гипервизор L1). В этом случае виртуальный процессор в этой гостевой системе L1 может использоваться для запуска вложенных виртуальных процессоров для виртуальных машин L2, управляемых вложенным гипервизором L1.

В этом случае вложенный гостевой гипервизор L1 будет переключать контекст между каждым из этих вложенных гостевых компьютеров L2 (VM A и VM B) и вложенным гостевым гипервизором L1. Таким образом, виртуальный процессор для виртуальной машины L1, поддерживаемый гипервизором L0, может запускать несколько разных доменов безопасности — вложенный контекст гипервизора L1 и один или несколько контекстов гостевой виртуальной машины L2. Поскольку гипервизор L0 поддерживает единое адресное пространство для виртуального процессора ВМ L1, это адресное пространство может содержать данные для вложенного гостевого гипервизора L1 и гостевых ВМ L2.

Чтобы обеспечить надежную границу изоляции между этими различными доменами безопасности, гипервизор L0 использует метод, который мы называем очисткой состояния, когда используется вложенная виртуализация. Благодаря очистке состояния гипервизор L0 избегает кэширования любого конфиденциального гостевого состояния в своих структурах данных. Если гипервизор L0 должен прочитать гостевые данные, такие как содержимое регистра, в свою частную память для завершения операции, гипервизор L0 перезапишет эту память нулями перед выходом из контекста гипервизора L0. Это гарантирует, что любое конфиденциальное состояние гостевого гипервизора L1 или гостевого виртуального процессора L2 не останется в кэше при переключении между доменами безопасности в гостевой виртуальной машине L1.

Например, если гостевой гипервизор L1 обращается к порту ввода-вывода, который эмулируется гипервизором L0, контекст гипервизора L0 становится активным. Чтобы правильно эмулировать доступ к порту ввода-вывода, гипервизор L0 должен будет прочитать текущее содержимое гостевого регистра для контекста гостевого гипервизора L1, и это содержимое регистра будет скопировано во внутреннюю память гипервизора L0. Когда гипервизор L0 завершит эмуляцию доступа к порту ввода-вывода, гипервизор L0 перезапишет любую память гипервизора L0, содержащую содержимое регистров для контекста гостевого гипервизора L1. После очистки внутренней памяти гипервизор L0 возобновит работу в контексте гостевого гипервизора L1. Это гарантирует, что конфиденциальные данные не останутся во внутренней памяти гипервизора L0 при вызовах контекста гипервизора L0. Таким образом, в приведенном выше примере не будет никакого чувствительного состояния гостевого гипервизора L1 в частной памяти гипервизора L0. Это снижает риск того, что конфиденциальное состояние гостевого гипервизора L1 будет перенесено в кэш данных в следующий раз, когда контекст гипервизора L0 станет активным.

Как описано выше, эта модель очистки состояния требует некоторой дополнительной обработки при использовании вложенной виртуализации. Чтобы свести к минимуму эту обработку, гипервизор L0 очень тщательно отслеживает, когда ему нужно очистить свою память, поэтому он может сделать это с минимальными накладными расходами. Накладные расходы на эту дополнительную обработку незначительны в измеренных нами сценариях вложенной виртуализации.

Наконец, очистка состояния гипервизора L0 гарантирует, что гипервизор L0 может эффективно и безопасно обеспечивать вложенную виртуализацию для гостевых виртуальных машин L1. Однако, чтобы полностью смягчить атаки между виртуальными машинами между гостевыми виртуальными машинами L2, вложенный гостевой гипервизор L1 должен реализовать устранение уязвимости L1TF. Это означает, что гостевой гипервизор L1 должен соответствующим образом управлять кэшем данных L1, чтобы обеспечить изоляцию конфиденциальных данных за границами безопасности гостевой виртуальной машины L2. Гипервизор Hyper-V L0 предоставляет гостевым гипервизорам L1 соответствующие возможности, позволяющие гостевым гипервизорам L1 выполнять сброс кэша данных L1.

Заключение

Используя комбинацию планирования ядра, изоляции адресного пространства и очистки данных, Hyper-V HyperClear может смягчить атаку спекулятивного выполнения L1TF по побочному каналу на виртуальных машинах с незначительным влиянием на производительность и с полной поддержкой SMT.

Обновление компонентов интеграции Hyper-V для виртуальных машин Windows

Windows Server 2012 R2 Datacenter Windows Server 2012 R2 Standard Windows Server 2012 R2 Essentials Windows Server 2012 R2 Foundation Windows 8.1 Enterprise Windows 8.1 Pro Windows 8.1 Windows Server 2012 Datacenter Windows Server 2012 Standard Windows Server 2012 Essentials Windows Server 2012 Foundation Windows Server 2008 R2 Service Pack 1 Windows Server 2008 R2 Datacenter Windows Server 2008 R2 Enterprise Windows Server 2008 R2 Standard Windows Server 2008 R2 Foundation Windows 7 с пакетом обновления 1 Windows 7 Ultimate Windows 7 Enterprise Windows 7 Professional Windows 7 Home Premium Windows 7 Home Basic Windows 7 Starter Windows Server 2016 , все версии Больше. ..Меньше

В этой статье описывается обновление для последних интегрированных компонентов для виртуальных машин (ВМ) Windows, работающих на узле под управлением Windows 10 или Windows Server 2016 или узле под управлением Windows Server 2012 R2. Это обновление доступно для гостевой системы Hyper-V на базе Windows Server 2012 R2, Windows Server 2012 и Windows Server 2008 R2 с пакетом обновления 1 (SP1). Прежде чем устанавливать это обновление, ознакомьтесь с разделом Предварительные требования.

Проблемы, исправленные в этом обновлении

Выпуск 1

Рассмотрим следующий сценарий:

• Вы подключаете виртуальную машину к виртуальному коммутатору, который использует физический адаптер.

• Вы включили параметр виртуализации ввода-вывода с одним корнем (SR-IOV) в Virtual Switch Manager.

• Вы отключили физический адаптер на гостевой машине Hyper-V, пока на виртуальной машине выполняется сетевой ввод-вывод.

В этом сценарии происходит сбой виртуальной машины.

Выпуск 2

Текущая реализация ведения журнала с опережающей записью (WAL) ошибочно предполагает, что владелец виртуального жесткого диска (VHD) никогда не меняется. Однако право собственности меняется при репликации нескольких групп виртуальных машин в сценарии с общим виртуальным жестким диском.

Как получить это обновление

Это обновление можно получить через Центр обновления Windows и Центр загрузки Майкрософт. Несмотря на то, что эта проблема наблюдалась только в Windows Server 2012 R2, Windows Server 2012 или Windows Server 2008 R2 с пакетом обновления 1 (SP1), обновление также применимо к Windows 8. 1 и Windows 7 с пакетом обновления 1 (SP1).

Важно! Если вы устанавливаете языковой пакет после установки этого обновления, вам необходимо переустановить это обновление. Поэтому перед установкой этого обновления рекомендуется установить все необходимые языковые пакеты. Дополнительные сведения см. в разделе Добавление языковых пакетов в Windows.

Метод 1: Центр обновления Windows

Это обновление предоставляется в качестве рекомендуемого обновления в Центре обновления Windows. Дополнительные сведения о том, как запустить Центр обновления Windows, см. в разделе Как получить обновление через Центр обновления Windows.

Метод 2: Центр загрузки Майкрософт

Следующие файлы доступны для загрузки из Центра загрузки Майкрософт.

Примечание. Эта загрузка не является самоустанавливающейся. См. Управление службами интеграции Hyper-V, чтобы узнать, как управлять интегрированными компонентами и устанавливать их. Чтобы начать загрузку, нажмите кнопку «Загрузить».

Для получения дополнительных сведений о том, как загрузить файлы поддержки Microsoft, щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Microsoft:

119591 Как получить файлы поддержки Microsoft из онлайн-служб
Microsoft проверила этот файл на наличие вирусов. Microsoft использовала самое последнее программное обеспечение для обнаружения вирусов, которое было доступно на дату размещения файла. Файл хранится на защищенных серверах, которые помогают предотвратить любые несанкционированные изменения в файле.

Подробная информация об обновлении

Предпосылки

Чтобы применить это обновление, необходимо иметь накопительный пакет обновления за апрель 2014 г. для Windows RT 8.1, Windows 8.1 и Windows Server 2012 R2 (2919355), установленный в Windows 8.1 или Windows Server 2012 R2. Или установите пакет обновления 1 для Windows 7 или Windows Server 2008 R2.

Информация о реестре

Чтобы использовать обновление из этого пакета, не нужно вносить никаких изменений в реестр.

Требование перезапуска

Возможно, вам придется перезагрузить компьютер после установки этого обновления.

Обновление информации о замене

Это обновление не заменяет ранее выпущенное обновление.

Статус

Корпорация Майкрософт подтвердила, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».

Ссылки

См.